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I.   INTRODUCTION 

Recognizing  tne  relationsnip  between  policies  and 
mechanisms  has  been  a  problem  in  tne  specification  and 
design  of  many  computer  systems.  What  is  needed  is  a  simple 
methodology  for  assessing  the  suitability  of  a  protection 
mechanism  to  enforce  a  non-discretionary  security  policy. 
Such  a  methodology,  based  upon  the  entity-relationship  model 
and  designed  with  validation  of  security  enforcement  as  its 
primary  objective,  is  presented. 

Defined  as  the  assignment  technique,  this  mathematically 
oriented  metnodology  establishes  a  relationship  between  the 
information  sensitivities  of  the  systems  entities 
(partitioned  according  to  the  policy  constraints),  to 
dominance  domains  (inherently  established  by  a  mechanism). 
The  assignment  technique  provides  a  means  for  mechanism 
sufficiency  validation,  since  the  results  of  the  assignment 
can  be  evaluated  to  determine  wnetner  the  constraints  of  tne 
policy  are  met. 

Mechanisms  are  defined  as  procedural  specifications  that 
prevent  the  occurrence  of  operations.  Protection  mechanisms, 
then  control  a  subject's  access  to  an  object,  by  adhering  to 
some  procedural  specification  of  access  rules.  Policies, 
however,  are  generally  stated  in  a  non-procedural  form.  This 
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leads  to  a  problem  in  translating  policies  into   mechanisms, 
and  in  verifying  the  accuracy  of  this  translation. 

Only  non-discretionary  security  policies  are  discussed 
in  detail.  Such  policies,  however,  are  extremely  important 
wnen  dealing  with  protection  of  business  information  as  well 
as  National  Security.  Computer  systems  designed  to  provide 
Command,  Control  and  Communications  must  rely  upon  effective 
non-discretionary  security  if  they  are  to  be  of  any  value  to 
National  Defense  [lj .  Compromise  and  subversion  policies  [2J 
precisely  define  the  requirements,  but  the  suitability  of  a 
protection  mechanism  to  meet  these  requirements  is  not 
always  apparent.  A  theoretical  foundation  from  which  this 
suitability  may  be  simply  and  readily  derived  is 
established. 

A.   BACKGROUND 

Non-discretionary  policies  for  tne  security  of  sensitive 
information  have  existed  throughout  the  annals  of  history. 
The  basis  of  these  policies  lies  in  a  subject  (i.e.,  an 
active  entity)  being  prohibited  modification  or  observation 
of  an  object  (i.e.,  a  repository  for  information  or  inactive 
entity)  based  upon  the  subject's  membership  in  a  specified 
group.  This  grouping  is  established  external  to  the  system 
in  which  it  will  be  used. 

The  first  computer  systems  dealt  with  the  problem  of 
security  by  establishing   physical   protection   perimeters. 


Walls,  loclrs  and  marines  with  rifles  provided  the 
environment  necessary  for  system  security.  Tnis  was  an 
acceptable  procedure  because  there  were  relatively  few  users 
of  tne  system  and  eacn  user  was  trusted  not  to  violate  tne 
security  policies.  Security  was  an  issue  external  to  tne 
computer  itself. 

However,  as  computer  technology  became  more 
sophisticated,  user  expectations  increased.  Policy-maKers 
established  security  policies  and  expected  their  machines  to 
adhere  to  them  without  exception.  The  security  perimeters 
that  had  been  established  external  to  tne  computer,  were  now 
to  be  established  internally. 

This  led  to  two  fields  of  research.  One  group,  the 
experimentalists,  attempted  to  design  ingeniously  contrived 
mechanisms  with  little  or  no  concern  for  tne  policies  which 
their  mechanism  would  support.  Mathematicians,  on  the  other 
hand,  set  about  tne  tasfc  of  modeling  policies  in  a  fashion 
that  would  establish  a  foundation  for  the  procedural 
specification  of  protection  mechanisms.  The  relationship 
between  these  models  and  the  mechanisms  was  not  always 
clear. 

What  is  needed,  and  what  is  presented  nere,  is  a  simple, 
complete  and  consistent  means  of  establishing  that  a 
mechanism  actually  enforces  the  policy-maicers ' 
specifications.  This  is  done  by  first  giving  the 
policy-mater  a  tool   to   precisely  describe  his  policy  and 
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then  giving  the  systems  designers  and  analysts  a  technique 
to  evaluate  the  sufficiency  of  their  mecftanism  to  support 
tnis  policy. 

A  careful  examination  of  tne  fundamental  nature  of 
non-discretionary  security  policies  and  protection 
mecnanisms  is  made.  Tnis  examination  is  based  largely  upon 
tne  findings  of  research  associated  with  security  Kernel 
tecnnology  [3J .  Tne  results  of  this  examination  snow  wnat  it 
is  about  mechanisms  that  actually  provides  the  protection 
and  what  protection  is  actually  provided.  In  so  doins>,  a 
theoretical  mathematical  foundation  is  established  from 
which  the  science  of  secure  computation  may  proceed  to  meet 
the  requirements  of  the  policy-mafcer  in  a  simple,  elegant 
and  efficient  manner. 

B.   RELATED  WORK 

Research  in  establishing  the  suitability  of  protection 
mechanisms  to  meet  non-discretionary  security  policies  is 
practically  non-existent.  Protection  mechanisms  are  usually 
presented  in  an  informal  manner  with  implementation  details 
dominating  the  discussion  [4] .  Policies,  on  the  other  hand, 
are  generated  by  persons  wno  rarely  give  consideration  to 
the  implementation  of  these  policies  in  a  computer  system. 
The  disparity  between  these  two  groups  has  led  to  little 
research  in  methodologies  for  bridging  the  broad  gap  between 
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security  policies  and  protection  mecnanisms,  and  even  less 
results. 

The  notion  of  domains  originated  witn  Dennis  and  Van 
Horn  [5J  and  tneir  concept  of  spneres  of  protection.  Tnis 
idea  was  improved  upon  by  Lampson  [6,?J  wno  coined  the  term 
"domain"  and  noted  tne  usefulness  of  domains  as  a  conceptual 
tool  for  understanding  protection  mecnanisms.  Scnroeder  [Sj 
made  use  of  tnese  ideas  to  design  a  protection  mecnanism 
that  would  allow  mutually  suspicious  subsystems  to  cooperate 
in  a  single  computation. 

Popes  [9J  modeled  tne  nature  of  access  control  witn  ni s 
restriction  srraphs.  Bell  and  LaPadula  [10]  made  a 
significant  contribution  wnen  tney  identified  a  matnematical 
framework  within  which  to  deal  witn  tne  problems  of  secure 
computer  systems.  Tneir  work  was  based  upon  general  syste-ns 
theory  and  finite  state  automata.  Furtek  [ll J  estatiisned  a 
similar,  less  Known,  matnematical  framework  based  upon  tne 
theory  of  constraints.  Tne  Bell  and  LaPaauia  work  was 
followed  by  Walters  [12J  development  of  a  lattice  model  for 
security  policies.  This  model  was  refined  and  later 
popularized  by  Denning  [13]  such  that  today,  nearly  all 
practical  policies  nave  been  recognized  as  lattice  policies. 

Saltzer  and  Schroeder  [14]  presented  a  tutorial  on  tne 
basic  principles  of  protection  in  computer  systems.  Conen 
[15],  however,  provides  a  far  more  rieorous  discussion  of 
protection  mecnanisms  wnile  Gronns'  [16J   researcn  provides 
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considerable   insight   into   a  number   of  details  regarding 
access  relations. 

Mucn  of  tnis  early  wort  was  directed  towards  tne 
solution  of  tne  computer  security  problem  in  National 
Defense  [12,17J.  As  sucn,  tne  autnors  rarely  diseased  tne 
motivation  for  their  efforts.  It  was  Scnell  UJ  ,  However, 
wno  dramatically  described  tne  importance  of  tne  computer 
security  in  a  modern  electronic  environment.  Recognition  of 
tne  significance  of  tnis  problem  motivated  tne  researcn 
reported  here. 

C.   ORGANIZATION 

The  relationship  between  security  policies  and 
protection  mechanisms  is  not  obvious.  In  order  to  explore 
this  relationship,  one  must  clarify  tne  meaning  of  security 
and  protection.  Only  by  methodically  examining  each  and 
every  pertinent  principle  can  one  nope  to  establish  a 
mathematical  framework  which  unifies  the  security  policy 
issues  with  the  protection  mecnanisms'  design. 

The  nature  of  non-discretionary  security  policies  is 
considered  first.  The  meaning  of  access  relations  is 
explored  and  commonly  fcnown  policies  are  discussed. 

Next,  a  formalized  notion  of  domains  is  presented.  A 
succinct  mathematical  definition  of  a  domain  is  offered.  The 
notion  of  an  (access-mode)  domain  and  dominance  domains  are 
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introduced  as  tools  for  precisely  cbaracterizing  protection 
mechanisms. 

Section  four  discusses  tne  tneoretical  basis  for 
assignment.  The  assignment  technique  is  explained  and  a 
means  for  simplifying  tne  tne  number  of  assignment  schemes 
needed  to  establish  the  insufficiency  of  a  mechanism  to 
support  some  particular  policy  is  derived. 

Section  five  presents  detailed  applications  of  simple 
assignment  snowin?  the  usefulness  of  the  assignment 
tecnnique  particularly  witn  respect  to  mecnanism  sufficiency 
validation.  Section  five  dispells  much  of  the  mystery  that 
surrounds  tne  ad  hoc  design  of  secure  computer  systems. 

Every  attempt  has  been  made  to  provide  the  reader  with  a 
clear  understanding  of  the  principles  of  the  assignment 
technique.  Readers  are  encouraged  to  question  these  findings 
and  indeed,  the  fundamentals  upon  which  they  are  based.  Only 
in  so  doing,  can  one  nope  to  grasp  the  meaning  of  the 
principles  presented  and  the  utility  of  the  assignment 
technique  in  establishing  a  foundation  for  secure  computer 
systems. 
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II  .   NON-DISCRETIONARY  SECURITY  POLICIES 

This  section  provides  a  detailed  examination  as  to  tne 
nature  of  non-discretionary  security  policies  after  first 
discussing  several  pertinent  concepts  concerning  policies  in 
general.  Some  of  tne  issues  presented  may  appear  to  confuse 
policy  issues  with  mechanism  issues.  Hopefully,  tnis 
confusion  will  be  resolved  as  tne  reader  obtains  a  tnorougn 
understanding  of  tne  innerently  isomorpnic  nature  of 
policies  and  mechanisms,  as  substantiated  in  tne  ensuing 
discussion. 

A.   THE  NATORE  OF  K    POLICY 

The  fundamental  nature  of  a  policy  has  not  been  clearly 
established  in  tne  Computer  Science  field.  For  example, 
Wulf,  Cohen,  Jones  and  others  surest  that  a  policy  is  a 
mecnanism  vnen  discussing  HYDRA  [1SJ .  Jones  subsequently 
discusses  ho*  protection  mechanisms  can  be  used  to  enforce 
security  policies  [19J .  On  the  otner  nand ,  Cohen  defines  a 
policy  as  a  problem  in  his  doctoral  dissertation  [15]  but, 
enumerates  several  protection  problems  associated  with  one 
security  policy  [15 J  .  Such  confusion  among  such  a  closely 
related  eroup  of  computer  scientists  specializing  in 
operating  system  security  is  by  no  means  an  isolated 
situation. 


15 


Snyder  [20J  mates  note  of  tnis  problem  staling  tnat 
capability-based  protection  systems  designers  rarely 
consider  the  security  policies  their  system  may  implement. 
Throughout  the  computer  security  literature,  one  may  observe 
that  the  nature  of  a  policy  and  how  it  relates  to  the 
protection  issues  discussed,  is  often  ignored.  Fernaps  tnis 
is  because  the  nature  of  security  policies  themselves,  and 
the  suitability  of  protection  mechanisms  to  meet  these 
policies  is  not  clearly  understood.  It  is  the  intent  of  this 
autnor  to  address  this  problem.  In  order  to  do  so,  one 
besrins  by  formalizin*  the  notion  of  a  policy. 

A  policy  is  a  specification  of  benavior.  Such  a 
specification  constrains  the  activities  within  a  system  by 
establishing  a  distinction  between  acceptable  and 
unacceptable  behavior  for  some  set  of  classes  established  by 
the  policy.  When  dealing  with  the  security  issue,  the 
classes  (i.e.,  access  classes)  are  simply  labels  which  the 
policy  uses  to  distinguish  between  eroups  of  system 
entities.  So  a  security  policy  specifies  a  set  of  access 
classes  and  identifies  tne  acceptable  behavior  between  them. 

Enforcement  of  policies  may  be  realized  in  a  number  of 
ways.  In  general,  any  means  of  security  enforcement  internal 
to  the  computer,  may  be  considered  to  be  a  protection 
mechanism.  As  such,  implementation  details  are  generally 
ignored. 
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Tne  term  benavior  generally  implies  mat  an  active 
entity  is  dealing  with  some  other  entity  or  entities.  So  one 
can  distingui stt  between  two  types  of  entities  witn  respect 
to  security  policy  specifications.  One  type  is  tnose 
entities  wnose  benavior  is  being  controlled.  Tnese  are  tne 
active  entities  within  tne  system  and  are  referred  to  as 
"subjects".  Tne  otner  type  is  tnose  witn  wnicn  tne  subject 
interacts  during  execution  tnat  are  not  subjects,  but  rather 
are  simply  repositories  of  information  [12J .  These  are  tne 
passive  entities  within  the  system  referred  to  as  "objects". 

A  process  is  characterized  by  an  address  space  and  an 
execution  point  or  state  of  its  virtual  processor.  It  is 
important  to  note  tne  distinction  between  processes  and 
subjects  as  these  two  terms  are  often  incorrectly  considered 
to  be  synonyomous.  A  subject  is  implemented  as  a 
process-domain  pair  [6,7,8] .  One  must  tafce  care  not  to 
confuse  tnese  two  terms. 

Much  confusion  has  been  associated  with  the  issue  of 
policy  enforcement.  A  policy  may  be  completely  enforced  in  a 
system,  partially  enforced  in  a  system  or  not  enforced  at 
all.  Partial  enforcement  applies  only  to  complex  policies 
for  wnicn  sub-policies  can  be  formulated  and  enforced. 
Partial  enforcement  does  not  imply  enforcement  of  a  policy 
only  under  certain  conditions,  or  at  certain  times,  wnicn 
is,  in  fact,  no  enforcement  at  all.  Partial  enforcement 
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refers  to  enforcement  of  a  sub-policy  witnin  tne  context  of 
the  overall  policy. 

Policies  are  not  problems  [15J  .  Problems  occur  only  in 
the  implementation  of  a  policy  and  are  used  to  descrice 
pitfalls  in  tne  enforcement  of  some  policy  of  interest. 

Applying  some  policy  to  a  system  mates  no  changes  to 
tnat  system  at  tne  time  of  application.  Tnis  means  tnat 
policies  do  not  initially  alter  the  entities  with  which  they 
deal.  Rather,  entities  are  assigned  to  an  access  class 
according  to  the  policy.  If  an  entity  is  assigned  to  an 
access  class  sucn  tnat  its  attributes  require  modification, 
or  its  relationships  are  invalid,  or  the  entity  itself  does 
not  belong  within  tne  system,  tne  system  is  not  in 
compliance  with  the  policy.  Action  may  be  ta&en  later  to 
bring  tne  system  into  compliance,  but  simply  associating  tne 
policy  with  the  system,  in  effect,  only  labels  tne  system 
entities. 

Recognizing  the  nature  of  a  policy  is  important  if  one 
is  interested  in  enforcement  of  policies  in  computer 
systems.  This  is  because  tne  logical  nature  of  a  computing 
device  dictates  a  logical  specification  of  policy.  Having 
clearly  described  tne  nature  of  a  policy  in  general,  cne  may 
now  examine  security  policies. 


18 


B.   SECURITY  POLICIES 

Security  policies  are  generally  grouped  into  two  broad 
classes.  Non-discretionary  security  policies  (sometimes 
referred  to  as  mandatory  policies),  are  policies  which  fix 
tne  classification  of  information  sensitivities  and 
establish  all  permissible  access  relations  (viz.,  subjects 
gaining  some  form  of  access  to  objects)  according  to  tnese 
information  sensitivities.  Sucn  a  policy  is  generally 
considered  to  externally  constrain  wnat  access  is 
permissible  [3 J .  Enforcement  of  a  policy  requires  that  tie 
sensitivity  of  ail  objects  and  tne  autnorizat ions  of  all 
subjects  be  clearly  identified. 

Discretionary  policies,  in  a  sense,  provide  a  finer 
granularity  of  access  control  witnin  tne  constraints  of  tne 
non-discretionary  policies  of  the  system  [3] .  Authorization 
to  access  information  and  specification  of  source 
information  access  classes  are  made  outside  of  the  computer 
environment.  A  policy  is  discretionary  wnen  a  subject  with 
access  to  an  object  may  exercise  its  discretion  in  making 
tnat  object  available  to  some  otner  subject.  As  sucn,  tne 
information  sensitivity  of  an  object  is  decided  in  a 
discretionary  or  arbitrary  manner.  This  tends  to  produce 
"spaghetti  howl"  policies  where  tne  information 
sensitivities  of  objects  is  not  easy  to  determine.  The 
sensitivity  of  objects  is  constantly  changing  in  an 
arbitrary  manner  which  may   not   be   readily  observable   or 
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controllable.  Sucn  policies  are  not  practical  wnen  dealing 
witn  many  of  tne  National  Defense  issues.  Because  of  their 
United  utility,  discretionary  policies  are  not  as 
interesting  as  non-discretionary  policies  nor  is  their 
enforcement  sucn  a  critical  issue. 

Only  non-discretionary  security  policies  are  examined  in 
tnis  discussion.  It  is  snown  tnat  all  non-discretionary 
security  policies  can  be  represented  as  lattice  security 
policies. 

C.   LATTICE  SECURITY  POLICIES 

A  number  of  non-discretionary  security  policies  have 
already  been  described  as  lattice  policies  [12,21j.  As  sucnt 
the  precise  form  of  the  lattice  structure  is  helpful  in 
understanding  tne  nature  of  tne  policy  [19J  . 

A   universally   bounded   lattice   is   a   mathematical 

structure  consisting  of  a  finite,   partially  ordered  set  for 

which  there  exists  precisely  one  least   common  upper  element 

(i.e.,   tne   least   upper   bound   (LUB))   and   precisely  one 

greatest   common   lower  element   (i.e.,   the  greatest  lower 

bound  (GLB))  [22,23j .   A  partially  ordered  set,  is  a  set,  0, 

for  which   a  relation,  R,   is  applied   to  Q   such  that  R  is 

reflexive,  antisymmetric  and  transitive  [22j .    For   example, 

consider  the  set  0  =  {  q.,  q  „,  q  .  q,  }  and  the  relation   R 

12    3    4 

applied   to  Q  sucn  tnat  q  Rq   (i.e.,  q   is  related  to  q   ty 

12  1  2 

relation   R),    q   Rq    ,   q   Rq    ,    q   Rq    ,    and   q   Rq    .      The   relation   R 
131424  34 
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foms  a  lattice  on  tne  set  0   witn  q   as  tne   GLB   and  q   as 

1  4 

the  LUB. 

When  discussing  lattice  security  policies,  one 
recognizes  trie  set  0  as  the  set  of  access  classes 
established  by  the  policy.  The  access  relation  R,  however, 
may  vary  significantly  from  policy  to  policy.  This  fact  is 
not  so  well  recognized.  Dennin^s  information  flow  model 
[13J  ,  for  example,  describes  a  flow  relation,  "  — V,  defined 
on  pairs  of  access  classes  such  that  for  classes  A  and  B,  A 
— ^  3  if  and  only  if  information  in  class  A  is  permitted  to 
flow  into  class  B.  This  relation  applies  to  compromise  and 
subversion  policies,  for  example,  but  is  meaningless  wnen 
discussins  proeram  integrity. 

Tnree  relations  between  access  classes  are  generally 
sufficient  to  describe  the  specifications  of  any 
non-discretionary  security  policy.  For  access  classes  A  and 
B,  these  are  : 


A  >  B   Information  of  access  class  A 
is  more  sensitive  tnan 
information  of  access  class  B 

A  =  B  Information  of  access  class  A 
is  of  the  same  sensitivity  as 
information  of  access  class  B 

A  n   B   Information  of  access  class  A 
is  in  no  way  related  to 
information  of  access  class  B 


The   notion   of  sensitivity  may  be  easily  confused  wnen 
discussing  several  policies.  Tnis  is  because  the  term   taices 
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its  meaning  from  the  policy  in  question  and  cannot  be 
readily  associated  witn  two  diverse  policies.  For  example, 
an  object  0  may  be  >  a  subject  S  witn  respect  to  one  policy, 
#  witn  respect  to  anotner  policy,  and  S  >  0  witn  respect  to 
still  anotner  policy.  Sensitivity,  tnen,  may  not  be  useful 
for  discussing  multiple  policy  issues.  It  is  nowever,  a 
useful  intuitive  term  for  describing  the  lattice  nature  of  a 
policy. 

This  autnor  advances  the  nypotnesis  tbat  all 
non-discretionary  security  policies  may  be  represented  as 
lattice  policies.  A.  simple  argument  is  offered  in  support  of 
tnis  Hypothesis  as  a  complete  proof  has  not  been  developed. 

Non-discretionary  security  policies  are  estaciisned 
external  to  the  computer  system  environment.  As  sucn,  they 
define  some  form  of  benavior  between  subjects  and  objects 
from  which  the  system  may  not  deviate  without  external 
authoritative  approval.  The  system  entities  (i.e.,  tne 
subjects  and  objects)  must  be  clearly  labeled  or  ctnerwise 
identified  witn  respect  to  the  policy.  Grouping  tnose  system 
entities  whose  labels  are  identical,  one  may  establish  a  set 
of  equivalence  classes  which  completely  partition  the 
systems'  entities.  One  may  tninfc  of  tnese  equivalence 
classes  as  labeled  by  the  access  classes.  Such  a 
partitioning,  for  all  practical  policies  and  systems  is 
finite. 
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One  nay  then  examine  the  relations  between  access 
classes  with  respect  to  the  policies.  Enumerating  all  tne 
relations  between  access  classes,  one  may  draw  a  .eraph,  such 
as  that  shown  in  figure  1,  with  nodes  signifying  access 
classes  and  arcs  signifying  that  the  access  class  of  the 
higher  node  (i.e.,  closer  to  the  top  of  the  pa,?e)  is  more 
sensitive  (>)  than  the  access  class  of  tne  lower  node. 
Transitive  relations  nsed  not  be  drawn  as  their  inclusion  is 
implicit  and  does  not  affect  the  graph. 


Figure  1.   Disjoint  Partially  Ordered  Sets  and  Nodes 

If  any  cycles  are  discovered,  in  an  attempt  to  construct 
tne  graph,  one  may  see  that  tne  specification  of  policy  is 
not  enforceable.  That  is  to  say,  for  some  cycle  of  access 
classes  A>B>...>Z>A,  the  information  sensitivity  of 
some  access  class  A  is  at  the  same  time  >  A  and  =  A.  This  is 
a  paradox.  Attempting  to  enforce  such  a  specification  is 
intuitively  nonsense!  So  if  one  is  to  have  a 
non-discretionary  security  policy,  viz.,  one  wnicn  is  to  be 
enforced  in  a  mandatory  fashion,  one  may  safely  assume  that 
the  policy  will  specify  no  cyclic  relations  among  tne  access 


23 


classes.  Therefore,  one  may  categorically  state  tnat  trie 
graph  of  any  enforceable  non-discretionary  security  policy 
will  never  contain  any  cycles. 

Furtner  examining  tne  grapn,  one  can  observe  tnat  only 
two  general  structures  may  exist.  Tne  first  consists  of 
unrelated  nodes  (i.e.,  tnose  nodes  wnicn  are  singletons 
representing  access  classes  wi tn  no  relations  to  other 
access  classes  in  the  ?raph).  Tne  other  structures  are 
partially  ordered  sets  (some  of  whicn  may  be  a  lattice). 


Figure  2.   lattice  Structure 


If  tne  grapn  does  not  contain  a  least  upper  bound, 
(LOB),  one  may  arbitrarily  create  an  access  class  so 
designated  and  establisn  tne  appropriate  relations  with 
respect  to  its  sensitivity  (see  figure  2).  This  access  class 
may  also  be  referred  to  as  tne  "system  nigh."  Likewise,  one 
may  do  the  same  for  the  greatest  lower  bound  (GLB)  which  is 
generally   Known  as  tne  "system  low."  Note  that,  neither  tne 
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LUB  nor  tae  GLB  need,  nave  any  entities  associated  with  their 
access  class.  By  forming  this  structure,  one  has  established 
a  lattice. 

Thus,  all  non-discretionary  security  policies  are 
lattice  security  policies.  Non-discretionary  security 
specifications  that  venerate  cyclic  structures  are  not  well 
formed  policies  and  as  sucnf  tneir  enforcement  cannot  be 
evaluated  nor  can  one  consider  such  a  specification  to  be  a 
policy  worthy  of  discussion. 

D.   SIMPLE  LATTICE  SECURITY  POLICIES 

A  policy  is  a  "simple  lattice  policy"  when  the  policy 
establishes  either  one  of  two  basic  lattice  structures.  The 
first  structure  is  formed  by  a  simply  ordered  (viz., 
linearly  ordered  or  totally  ordered)  set  of  access  classes. 
For  example,  some  policy  mignt  establish  a  simply  ordered 
structure  where  SECRET  is  more  sensitive  than  (>) 
CONFIDENTIAL  >  UNCLASSIFIED.  Policies  with  simply  ordered 
sets  of  access  classes  are  called  "hierarchical  policies." 

The  other  basic  lattice  structure  is  formed  by  a 
mutually  exclusive  set  of  access  classes.  For  example,  some 
policy  might  establish  a  mutually  exclusive  structure  where 
CRYPTO  is  not  related  to  (*)  NATO  #  NUCLEAR.  Those  policies 
with  mutually  exclusive  sets  are  called  "category  policies." 
One  should  note  that,  a  "compartment"  access  class,  e.ff., 
CRYPTO-NATO,   is   formed  when  some  restricted  form  of  access 
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is  available  to  two  or  more  otnerwise  mutually  exclusive 
categories  of  information. 

Recall  that  a  lattice  security  policy  partitions  the 
systems  entities  with  respect  to  their  information  sensitiv- 
ities, into  a  set  of  equivalence  classes  tnat  can  be  labeled 
by  tne  access  classes.  Consider  any  two  lattice  security 
policies,  P  and  P  ,  and  some  system  containing  a  non-empty 
set  of  entities,  A.  When  P  is  applied  to  tne  system, 
a   partition,   tt  ,   is   established   creatine  the   set   of 

equivalence  classes,  {  e  .  e  .  . . . ,  e  ,  . .  .  ,  e   }.   Applying 

12         i  n 

P2  to  this  system  so  partitioned,  refines  the  system 
producing  a  unique  partitioning  tt  .  tt  tnen,  is  simply  tne 
product  of  i.,  the  partition  induced  by  P  and  tt  ,  the 
partition  induced  by  P„  .  So  for  each  e  ,  an  equivalence 
class  created  by  P,,  a  new  set  of  equivalence  classes, 
{   e.,,   e.0  ,   ...,   e.   >,   is   produced.    Tne   partition 

ilT    iz  T  in  e  r 

tt  forms  a  lattice,  viz.,  that  induced  by  the  composite 
policy  P. 

It  readily  follows  that  all  lattice  security  policies 
are  the  product  of  one  or  more  simple  lattice  policies.  The 
total  non-discretionary  security  package  for  a  system  then, 
consists  of  some  set  of  simple  lattice  security  policies 
successively  refining  the  systems  entities,  none  of  which 
may  produce  conflicting  policies.  This  is  shown  to  be 
particularly  useful  Knowledge  when  one  attempts  to  use  the 
assignment  technique  as  a  means  of  security  validation. 
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E.   ACCESS  RELATIONS 

Any  specific  non-discretionary  security  policy  will 
distinguish  one  or  mor?  distinct  access  relations  between 
subjects  and  objects.  Associated  witn  tnese  distinctions  one 
may  derive,  where  not  otnerwise  specified,  tne  set  of 
"access  rights"  wnicn  may  be  accorded  to  tne  subject.   Tnese 

access  rights  specify  tne  liberties  wbicn  the  subjects  may 
tate  witn  respect  to  tnese  objects.  Access  rignts  are 
typically  mirrored  in  the  "access  modes"  of  the 
corresponding  protection  mechanism.  Although  there  exists  a 
fine  difference  between  an  "access  right"  and  an  "access 
mode",  viz.,  "access  rights"  are  associated  with  security 
policies  and  "access  modes"  are  associated  witn  tne 
protection  mechanisms  wnich  enforce  the  policy,  this 
discussion  frequently  refers  to  an  "access  right"  as  an 
"access  mode"  because  it  is  the  access  mode  which  must 
inevitably  be  questioned  when  evaluating  the  enforcement  of 
a  security  policy. 

The  enforcement  of  a  policy  is  fundamentally  limited  by 
tne  system's  granularity  of  access  which  may  also  be  thought 
of  as  the  system's  variety  or  richness  of  access  modes. 
Policies  that  prescribe  distinctions  not  recognized  by  the 
access  control  mechanisms  must  be  enforced  in  an  overly 
restrictive  manner  or  ignored.  For  example,  a  policy 
addressing  a  concatenation  access  relation  cannot  be 
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precisely  enforce!  on  a  system  that  does  not  recognize  some 
form  of  append  access  mode. 

The  basis  of  all  security  enforcement  evaluation  lies  in 
tne  acceptability  of  an  access  relation.  An  access  relation 
is  defined  as  a  tuple  (subject,  access  mode,  object).  This 
tuple  signifies  that  a  relation  between  tne  subject  and 
object  exist  such  that  the  suDject  is  permitted  to  access 
the  object  with  all  the  privileges  associated  with  the 
access  mode.  The  problem  of  information  security  may 
generally  be  expressed  as  the  problem  of  permitting  the 
existence  of  only  those  access  relations  that  in  no  way 
violate  any  of  the  applicable  systems  policies. 

One  can  see  then,  that  the  granularity  of  access  control 
within  a  system  is  dependent  upon  the  ability  to  distinguish 
attributes  of  subjects  and  objects  plus  the  distinct  access 
modes  available.  The  primitive  access  modes  (i.e.,  those 
access  modes  tnat  are  not  decomposable  by  the  system) 
associated  with  the  design  of  the  system,  including  the 
protection  mechanisms,  designate  the  associated  rights 
accorded  to  an  access  request. 

When  tne  granularity  of  access  is  successively  refined, 
one  may  observe  two  conflicting  phenomena.  First,  the 
ability  to  distinguish  between  access  relations  is  more 
pronounced,  thus  allowing  for  greater  sophistication  and 
variety  in  policy  formulation.  The  problem,  however,  is  that 
the  increased  distinctions  of  access  relations  increases  tae 
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complexity  of  the  security  evaluation  process.  Systems 
designers  are  face!  witn  tne  problem  of  striding  a  balance 
between  tne  granularity  of  access  and  tne  complexity  of 
system  security  validation. 

This  nas  not  deterred  tne  efforts  of  many  systems 
designers,  However,  as  tne  granularity  of  subjects  and 
objects  is  quite  refined  in  many  systems.  Unfortunately, 
sucn  systems,  almost  witnout  exception,  nave  failed  to 
enforce  even  minimal  non-discretionary  security  policies. 

Two  generic  access  modes  are  particularly  useful  in  tne 
discussion  of  security.  These  are  [16J  "observe"  (the 
ability  to  observe  information)  and  "modify"  (the  ability  to 
modify  information).  Other  access  modes  may  be  generally 
thought  of  as  a  finer  granularity  of  tnese  two  access  modes. 
Figure  3  illustrates  one  sucn  possible  set  of  primitive 
access  modes  and  how  they  are  associated  with  the  generic 
access  modes. 


Observe 


Modify 


Read   Execute   Write   Append 


Figure  3.   Generic  Access  Modes 

The  problem  of  computer  security  enforcement  can  be 
reduced  to  the  problem  of  limiting  the  access  relations 
within   the   system  to  only  those  tnat  neither  directly  nor 
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indirectly  violate  the  systems  security  policies.  If  one  can 
establish  that  all  of  the  access  relations  permitted  in  tie 
system  are  acceptable  to  the  policy,  one  has  established 
that  the  system  is  "secure." 

F.   ILLUSTRATION  OF  POLICIES 

In  reviewing  tne  computer  science  literature,  tnis 
author  was  unable  to  discover  any  illustration  forms 
appropriate  for  showing  the  features  of  non-discretionary 
security  policies  in  sufficient  detail  that  one  could 
readily  discern  all  permissible  access  relations  within  the 
system  simply  by  examining  the  illustration  alone.  This 
section  presents  a  review  of  the  major  forms  examined  and 
their  failure  to  adequately  illustrate  access  relations.  It 
also  provides  two  proposed  alternative  forms  that  more 
clearly  illustrate  access  relations  of  a  system  in  a  manner 
which  leaves  no  doubt  as  to  the  nature  of  the  policy  and  the 
requirements  for  its  enforcement. 

LUB 


fXBX' 


'GIB' 


Figure  4.   Basic  Lattice  Form 

Figure  4  shows  a  representation  for  a  lattice   structure 
commonly   found   in  mathematical  texts  [22,23j .  With  respect 
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to  lattice  security  policies,  each  node  represents  an  access 
class  and  the  arcs  signify  tnat  the  node  nearer  the  top  of 
tne  page  represents  an  access  class  which  is  more  sensitive 
than  tne  lower  nodes'  access  class.  Thus,  in  figure  4  one 
may  observe  that  A.  >  D  and  B  #  A.  Sometimes  these  arcs  are 
labeled  by  ">"  symbols,  but  this  merely  tends  to  clutter  the 
illustration  and  provides  no  additional  information.  Note 
that  this  form  provides  no  information  re^ardin*  access 
relations  without  some  examination  of  tne  policy  that  is 
being  illustrated,  e.g.,  one  cannot  readily  answer  the 
question  "can  a  subject  of  access  class  A  write  to  an  object 
of  access  class  D?" 

The  form  shown  in  figure  5  [12,13] ,  provides  basically 
tne  same  information.  This  form  illustrates  tne  permissible 
information  flow  that  is  immediate  and  non-reflexive  by 
means  of  directed  arcs.  Nodes  are  once  again  used  to 
represent  access  classes.  Access  relations  are  still 
non-discernible  by  examination  of  tne  illustration  alone. 


!X!x$ 


\t 

Figure  5.   Information  Flow  Form 
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Another  form  which  is  popular  in  capability-based 
protection  systems  researcn  [24j ,  illustrated  in  figure  6, 
is  called  a  protection  grapn  [20J .  Tnese  graphs  specify  each 
subject  as  a  solid  node,  "t",  and  each  object  as  an  empty 
node,  "0".  Tne  directed  arcs  between  nodes  specify  tae 
access  risrhts  of  the  source  by  the  associated  labels.  This 
form  provides  an  extremely  detailed  means  of  representing 
all  access  relations  within  the  system.  Unfortunately,  this 
form  provides  such  detail  that  an  illustration  of  any 
practical  system  becomes  exceedingly  busy.  Thus  one  quicfcly 
loses  the  ability  to  distinguisn  between  access  classes  even 
when  they  are  clearly  labeled.  What  is  needed  is  needed  is  a 
higner  order  of  abstraction  for  tne  presentation  of 
practical  systems. 
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Fiarure   6.      Protection   Graphs    [20] 
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Figure  7  represents  the  first  illustration  forn  proposed 
by  tnis  author  called  aa  "access  relation  graph".  In  tnis 
forn,  eacti  node  represents  an  access  class  as  specified  by 
tne  policy.  All  non-reflexive  immediate  access  relations 
[13]  between  access  classes  (except  tnose  tnat  may  be 
establisned  by  forming  a  transitive  closure  over  some  given 
access  mode(s))  are  grouped  by  access  mode  and  shown  as 
directed  arcs  labeled  by  the  associated  access  mode(s).  This 
form  solves  tne  problem  of  the  protection  graph  for 
non-discretionary  security  policy  representation  by 
providing  tne  minimum  information  necessary  for  one  to  fully 
grasp  all  the  security  implications  of  the  policy  from  a 
single  illustration. 
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Figure  7.   Access  Relation  Graph 
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An  access  relation  ^rapn  clearly  snows  ail  permissible 
access  relations  specified  by  a  non-discretionary  security 
policy.  Reflexive  relations,  i.e.*  tnose  with  a  subject  of 
the  same  access  class  as  the  object,  need  never  be 
specifically  cited  unless  all  access  modes  are  not  permitted 
witnin  an  access  class.  Antisymmetric  relations  are  clearly 
defined  by  tne  directed  arcs.  Transitive  relations  are 
inferred  from  tne  patn  of  two  or  more  antisymmetric 
relations  (viz.,  in  figure  7  a  subject  of  tne  LUB  access 
class  may  read  from  an  object  of  tne  SLB  access  class). 
Therefore,  tne  form  meets  tne  mathematical  requirements  for 
a  lattice  in  that,  all  access  relations  for  the  lattice 
(i.e.,  a  universally  bounded  partially  ordered  set)  are 
clearly  illustrated. 

In  its  most  delineated  case,  the  access  relation  graph 
is  reduced  to  a  protection  eraph.  The  advantage  of  the 
access  relation  graph  over  tne  protection  graph  is 
simplicity.  Only  the  access  relations  needed  to  represent 
tne  policy  are  snown.  Additionally,  complex  policies  and 
composite  policies  are  illustrated  in  one  simplified  form. 

Another  illustration  form  tnat  is  particularly  useful 
when  discussing  uniform  lattice  structures  (i.e.,  those 
access  relation  graphs  where  tne  access  modes  between  any 
two  antisymmetric  access  classes  are  identical)  is  the 
linear  access  sraph.  Such  a  erapn  shows  the  security 
label(s)  of   the   objects   (i.e.,   how   one   represents   the 
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sensitivity  of  the  object)  and  denotes  the  access  modes 
available  to  subjects  of  varying  sensitivity  witn  respect  to 
the  sensitivity  of  tne  objects.  Figure  9(A)  illustrates  a 
simple  general  linear  access  grapn.  In  tnis  figure,  subjects 
with  greater  sensitivity  than  the  objects  sensitivity  would 
enjoy  the  use  of  access  mode(s)  2  when  referencing  that 
object.  Subjects  of  inferior  sensitivity  than  the  objects 
sensitivity  would  enjoy  the  use  of  access  mode(s)  1  when 
referencing  that  object.  Subjects  of  the  same  sensitivity  as 
the  object  would  enjoy  access  modes  1  and  2  when  referencing 
the  object.  The  linear  access  grapn  for  tne  Multics  Ring 
Brackets,  first  pointed  out  to  the  author  by  R.  Schell,  is 
shown  as  an  example  of  a  familiar  policy  represented  in  this 
form  in  fieure  8(B) . 


System 
1  High 


access  mode(s)  2 


access  mode(s  )  1 

(security  System 

Label   }  Low 


(A) 


iRlng  0 


write 


execute 
f'Rli         R2 


read 


ISj 


call  as  a  gate 


(B) 


Figure  S.   Linear  Access  Graphs 
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The  disadvantage  of  tne  linear  access  grapn  is  tnat  it 
may  only  be  used  for  illustration  of  uniform  policies,  i.e., 
tnose  policies  wnere  tne  access  relations  between  any  two 
access  classes  (one  of  wnicn  is  more  sensitive  than  the 
otner)  are  identical.  Tne  succinct  nature  of  tnis  form, 
however,  mates  it  possible  to  capture  the  essence  of  a  class 
of  policies,  i.e.,  those  which  may  be  described  by  the  same 
linear  access  graph,  without  going  into  all  the  details. 

G.   EXAMPLE  POLICIES 

Having  discussed  the  nature  of  policies  in  general,  one 
is  now  prepared  to  examine  several  specific  policies  of 
interest.  Such  a  discussion  logically  begins  with  the  two 
broadest  classes  of  security  policies,  i.e.,  compromise  and 
subversion. 


Upper 
Limits 


Observe 


Sensitivi  ty 
Label        [ 


Modify 


Lower 
Limits 


Fisrure  9.   Compromise  Policy. 

A  compromise  policy,  sometimes  referred  to  simply  as  a 
security  policy,  is  one  wnose  primary  intent  is  to  pronibit 
the  unauthorized  observation  of  information.  Figure  9  show 
the  general  form  of  such  a  policy.  Subjects  may  observe  only 
those  objects  whose  sensitivity  is  less  than  or  equal  to  the 
subject's  sensitivity  in  order  to  prevent  direct  observation 
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of  an  object  by  an  unauthorized  subject,  viz.,  tne  Simple 
Security  Condition  [10J  .  In  order  to  prevent  indirect 
observation  of  objects  by  unautnorized  subjects,  a 
sufficient  but  not  necessary  condition  establishes  that 
modification  of  objects  must  at  least  be  limited  to  tnose 
subjects  whose  sensitivity  is  less  than  or  equal  to  the 
objects  sensitivity,  viz.,  tne  (Security)  Confinement 
Property  —  also  &nown  by  a  less  descriptive  title  as  the 
^-Property  [10]  . 

A  subversion  policy,  sometimes  referred  to  simply  as  an 
integrity  policy,  is  the  dual  of  a  compromise  policy.  The 
primary  interest  of  a  subversion  policy  is  to  prohibit  the 
unauthorized  modification  of  information.  Figure  10 
illustrates  these  general  characteristics.  Subjects  may 
modify  only  those  objects  whose  sensitivity  is  less  than  or 
equal  to  the  subject's  sensitivity  in  order  to  prevent 
direct  modification  of  an  object  by  an  unautnorized  subject, 
viz.,  the  Simple  Integrity  Condition  [21J  .  In  order  to 
prevent  indirect  modification  of  objects  by  unauthorized 
subjects,  a  sufficient  but  not  necessary  condition  is  that 
observation  of  objects  must  be  limited  to  tnose  subjects 
whose  sensitivity  is  less  than  or  equal  to  the  object's 
sensitivity,  viz.,  the  Integrity  Confinement  Property  [21J  . 


3? 
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Figure  10.   Subversion  Policy. 

Tne  importance  of  subversion  policies  snould  not  be 
underestimated  [2,21].  Changing  the  course  of  an  ICBM,  for 
example,  snould  in  most  cases  require  a  more  sensitive 
authorization  tnan  simply  knowing  its  course.  Sucn  policies, 
nowever,  are  often  overlooked  in  many  Command,  Control,  and 
Communications  systems  [2] . 

Anotner  general  class  of  policies  tnat  is  of  general 
interest  in  Security  Kernel  researcn,  and  whose  title  was 
coined  during  tne  course  of  this  researcn  effort  by  R. 
Schell,  are  the  "Program  Integrity"  policies  [4J  .  The  notion 
of  program  integrity  stems  from  tne  desire  to  pronlhit 
unauthorized  modification  of  executable  programs  by  less 
trustworthy  subjects.  In  the  general  case,  one  wisnes  to 
ensure  that  the  more  sensitive  programs  are  "tamperproof . " 
In  other  words,  one  wants  to  be  sure  tnat  tne  program  can  be 
"trusted"  to  perform  as  specified  and  can  not  be  "tric&ed" 
by  merely  reading  data  of  lower  sensitivity  or  "importance." 
For  example,  a  system  designer/programmer  may  wish  to  insure 
that  his  programs  always  perform  as  specified  in  botn  his 
test  environment  and  in  any  application  environment.  Unlifce 
a   strict   integrity  policy   [21J  ,  program  integrity  is  not 
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concerned  witti  the  issue  of  general  observation  of 
information.  Program  integrity  is  tnerefore  less 
conservative  (and  tnus  more  "ristty")  tnan  Bibas  integrity 
policy.  Program  integrity  deals  only  with  execution  and 
modification  of  information.  As  sucn,  figure  11  illustrates 
the  general  form  of  a  program  integrity  policy. 


Execute 
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Label 
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Modify 

Figure  11.   Program  Integrity  Policy. 

One  may  guarantee  that  no  direct  modification  of  a 
program  by  an  unauthorized  subject  (i.e.,  a  direct  threat^ 
is  possible  by  enforcement  of  the  following  condition  : 


Simple  Program  Integrity  Condition  :  If  a  subject 
has  modify  access  to  an  object,  then  tne  program 
integrity  of  the  subject  is  greater  than  or  equal 
to  tne  program  integrity  of  tne  object. 


Because  program  integrity  policies  are  concerned  with 
tne  execution  issue  (versus  tne  observation  issue  [21J  ) , 
indirect  modification  of  information  is  not  strictly 
pronibited.  This  provides  a  certain  degree  of  flexibility, 
but  also  produces  a  certain  amount  of  ristc  [19]  .  Confinement 
of  execution  reduces  the  ris&  of  sucn  an  indirect  tnreat  but 
does  not  eliminate  it.  A  more  sensitive  subject  must  he 
trusted   not   to  modify  a   less   sensitive  object   either 
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intentionally  or  otnerwise.  An  indirect  tnreat  occurs  wnen  a 
subject  executes  a  program  that  has  been  modified  by  a  less 
trustvortny  subject,  tnerefore,  one  wisnes  to  confine  tne 
execution  access  relations.  The  confinement  property  for 
program  integrity  is  defined  as  follows  : 


Program  Integrity  Confinement  Property  :  If  a 
subject  nas  execute  access  to  an  object,  then  tne 
program  integrity  of  tne  object  is  greater  than  or 
equal  to  the  program  integrity  of  the  subject. 


The  remainder  of  the  section  discusses  tnree  policies  of 
general  interest  to  federal  ADP  users.  Any  computer  system 
designed  for  use  by  the  federal  government,  should  as  a 
minimum,  consider  its  ability  to  enforce  these  policies. 

1 .   National  Security  Policy 

The  National  Security  Policy  classifies  information 
essential  to  the  National  Defense  or  foreign  relations  of 
the  United  States.  The  President  of  tne  United  States 
established  this  policy  in  Executive  Order  Number  12065 
dated  June  26,  1378  [25].  This  order  defines  three  levels  of 
classification  as  follows  : 


TOP  SECRET  :  That  information  or  material  the 
unautnorized  disclosure  of  wnicn  could  reasonably 
be  expected  to  cause  exceptionally  grave  damage  to 
the  national  security. 

SECRET   :   Tnat   information   or  material    the 

unauthorized   disclosure  of  which  could  reasonably 

be  expected  to  cause  serious  damage  to  the 
national  security. 
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CONFIDENTIAL  :   That   information  or  material  the 

unautnorized  iisclosure  of  wnicn  could  reasonably 

be  expected  to  cause  damage   to   the  national 
security. 


Implicit  in  this  set  of  definitions,  tnere  also 
exists  a  classification  of  information  which  is  not 
classified.  Tnerefore,  one  nas  four  hierarcnical  access 
classes  established  by  this  policy,  the  intent  of  which  is 
to  prevent  unauthorized  disclosure  (viz.,  observation)  of 
information  so  classified.  Figure  12  shows  the  access 
relation  grapn  for  tnis  compromise  policy  wnicn  is  referred 
to  as  the  basic  National  Security  Policy. 

Executive  Order  12065  also  establisnes  [25J  tne 
authority  to  originally  classify  new  information. 
Information  may  be  classified  Top  Secret  only  by  officials 
designated  in  writing.  Information  may  be  classified  Secret 
only  by  officials  wno  nave  Top  Secret  classifications  or  cy 
officials  designated  in  writing.  Information  may  be 
classified  Confidential  only  cy  officials  witn  Top  Secret  or 
Secret  classifications  or  by  officials  designated  in 
writing. 

In  order  to  obtain  access  to  classified  material, 
the  order  indicates  that  a  person  must  be  determined 
trustwortny  (granted  clearance)  and  tnat  access  is  necessary 
in  the  performance  of  that  persons'  duties  ("need  to  Know"). 
This  is  a  discretionary  policy,  nowever,  and  will  be 
discussed  no  further.   All   classified  material  shall  be 


41 


appropriately  and  conspicuously  marlced  to  put  all  persons  on 
clear  notice  tnat  tne  information  is  classified.  Classified 
material  no  longer  needed  shall  be  promptly  destroyed. 


Observe} 


{Modify 


Observe} 


{Modify 


Observe} 


{Modify 


Figure  12.   Basic  National  Security  Policy. 

2.   National  Integrity  Policy 

The  dual  of  tne  National  Security  Policy  is  the 
National  Integrity  Policy  [21J .  Motivation  for  sucn  a  policy 
comes  from  the  desire  to  prohibit  subversion,  i.e.,  trie 
unauthorized  modification  of  information.  The  following  set 
of  integrity  classes  nave  been  established  for   tnis   policy 
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[21]  •  Implicit  witti  this  classification  scheme,  one  also  nas 
information  that  is  not  classified. 


TOP  SECRET  :  That  information  or  material  the 
unauthorized  modification  of  which  could 
reasonably  be  expected  to  cause  exceptionally 
grave  damage  to  the  national  security. 

SECRET  :  That  information  or  material  the 
unautnorized  modification  of  wnicn  could 
reasonably  be  expected  to  cause  serious  damage  to 
the  national  security. 

CONFIDENTIAL  :  That  information  or  material  the 
unauthorized  modification  of  which  could 
reasonably  be  expected  to  cause  damage  to  the 
national  security. 


One  further  point  concerning  Integrity  Policies  must 
be  emphasized  before  one  proceeds.  Generally  speaking,  one 
has  a  good  notion  of  how  to  classify  information  with 
respect  to  security  and  unautnorized  observation,  but 
classification  with  respect  to  integrity  is  not  so  easily 
identified.  In  some  sense,  integrity  classification  must  be 
determined  by  the  object's  potential  importance  rather  than 
by  its  current  Importance.  Consider,  for  example,  a  simple 
sine  function  tuc&ed  away  in  some  obscure  user  library.  If 
this  function  is  used  to  compute  trajectories  for  an 
inter-continental  ballistic  missile,  it  becomes  TOP  SECRET 
with  respect  to  the  National  Integrity  Policy,  wnereas,  it 
is  clearly  UNCLASSIFIED  with  respect  to  the  National 
Security  Policy.  Classification  of  information  witn  respect 
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to  integrity  will  generally   require   considerable  planning 
and  foresight  [2J  . 
3.  Privacy 

The  Code  of  Fair  Information  Practices  and  tne 
Privacy  Act  of  1974  establisned  tne  following  basic  policy 
for  the  Federal  Government  [26] . 


(1)  There  must  be  no  personal  data  record-Keeping 
systems  whose  very  existence  is  secret. 

(2)  There  must  be  a  way  for  an  individual  to  find 
out  what  information  about  him  is  on  record  and 
now  it  is  used. 

(3)  Tnere  must  be  a  way  for  an  individual  to 
correct  or  ammend  a  record  of  identifiable 
information  about  him. 

(4)  There  must  be  a  way  for  an  individual  to 
prevent  information  about  him  that  obtained,  for 
one  purpose,  from  being  used  or  made  available  for 
other  purposes  without  his  consent. 

(5)  Any  organization  creatine,  maintaining,  usin? 
or  disseminating  records  of  identifiable  personal 
data  must  guarantee  tne  reliability  of  the  data 
for  their  intended  use  and  must  taice  precautions 
to  prevent  misuse. 


All  information  systems  (including  computer  systems) 
used  by  tne  Federal  Government  are  subject  to  these  privacy 
requirements  and  must  incorporate  a  corresponding  set  of 
safeguards  when  the  process  "Privacy  Information." 

These  three  policies  are  applicable  to  many  Federal 
data  processing  applications.  Numerous  other 
non-discretionary  policies  exist  botn  in  tne  Federal,  State, 
and  Local  governments  and  in  private  industry.  It   has   been 
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shown   in   this  section  that  these  policies  may  be  precisely 

described  using  access  relation   erapns   or   linear   access 

graphs   as  described  in  this  section.  Once  a  policy  has  been 

so  described,  a  precise  evaluation  of  its  enforcement  may  be 
considered. 
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Ill .   A  FORMALIZ£D  NOTION  OF  DOMAINS 

The  notion  of  a  "domain"  has  not  been  clearly  presented 
in  a  precise  manner,  nor  properly  defined.  Dennis  [5J 
introduced  the  concept  by  describing  a  "sphere  of 
protection."  Lampson  [6J  refined  tne  concept,  coining  the 
term  "domain",  and  defined  a  domain  as  a  *roup  of 
capabilities  or  protected  names.  Scnroeder  [Bj  maintains 
Lampson's  definition,  hut  provides  an  in-depth  discussion 
and  presentation  of  his  ideas,  many  of  wnicn  were 
instrumental  in  the  formulation  of  the  concepts  presented 
nere.  Scnroeder  further  refined  the  ideas  from  nis  tnesis, 
and  together  with  Saltzer  [l4j,  defines  a  domain  as  a  set  of 
objects  that  may  be  accessed  by  a  principal.  This  definition 
is  the  most  commonly  accepted  today,  but  for  any  rigorous 
discussion  of  iomains,  or  for  presentation  of  a  concept  su~h 
as  tne  assignment  technique,  a  more  formalized  definition  is 
needed. 

An  access  domain   A,  is  a  tuple,  (a,,  a2 ,  ....  a.,  ..., 

a      ),   where   n  is   the   number   of  primitive      (non-decomposable) 

access   modes   in  the   system  and  a.    is    the   set   of   all   objects, 

{  0 ,,      0„,    ...»      0  .   ,    ...,   0      },      accessible      by     the      "i"th 
12  j  m 

access   mode.        An    (access   mode)-domain   is    the   set   of  objects 
that   a   process   executing  in    that  domain      (i.e.,      a     subject) 
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has  the  risrfit,   or  privilege  of,   accessing  according  to  the 
rules  for  tnat  particular  access  mode. 

Consider  the  following  examples  of  domains: 


A  :  (Observe(O) :{A} ,  Modify (M) : {3}  ) 


A2:  (0:{A,B,C},  M:{A,E,C}  ) 


A3:  (0:{A,C,D>,  M:{^}  ) 


A4:  (0:{A,B,C,D>,  M:{A,B,C,D}  ) 


The  observe-domain  of  A,  (denoted  as  OA,  )  is  object  A 
and  the  modify-domain  MA.,  is  object  B.  Note  that  simply 
referring  to  A.,  as  containing  objects  A  and  E  would  not 
provide  much  insight  into  the  true  nature  of  this  domain 
[141. 

The  notion  of  "dominance"  with  respect  to  domains  was 
introduced  by  Srohn  [16] .  These  notions  are  refined  from 
security  dominance  and  integrity  dominance  to  a  more  general 
definition  of  dominance. 

A  domain,  Ai   dominates  (  °< )   A.  if  and  only  if   (iff) 


for  each   access   mode   a  ,   aAj   j£.   aA^.      This   is 


particularly  useful  wnen  discussing  the  relationship 
between  domains  with  respect  to  access  modes.  One  can  say 
tnat   for  some  cl  ,  sl  a  .  «<:  a.  A  .    iff  u.   c,   \A.  . 

Continuing  with   the  previous  group  of  example  domains. 


OA4  «*  OA3,   OA3  °<    OA1,   *A4 


MA3,   MA, 


MA3, 
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,-v  a  but  A-  does  not  dominate  A,  •  Similar  examples 
can   be  formulated  by  the  reader. 

Dominance  domains  may  te  labeled  for  convenience.  In  tne 
Multics  system,  for  example,  the  dominance  domains 
established  by  tne  ring  mecnanism  were  Known  as  rings  and 
were  labeled  by  ring  numbers.  Schroeder's  protection 
mechanism  also  uses  numbers  as  labels  for  dominance  domains 
[8J. 

The  systems  protection  mechanisms  establish  a  set  of 
dominance  domains  that  can  be  used  for  evaluating  the 
protection  mechanisms.  These  dominance  domains  dominate  all 
domains  that  currently  exist  or  may  exist  within  the  system. 
If  one  can  establish  the  set  of  dominance  domains  for  the 
system  and  one  can  snow  that  tne  policy  holds  for  these 
domains,  then  one  can  show  that  the  policy  holds  for  all 
domains. 

A  mechanism,  in  the  most  general  sense,  is  something 
that  prevents  the  occurrence  of  certain  sequences  of 
operations  [15].  A  protection  mechanism,  or  an  access 
control  mechanism,  can  be  defined,  as  sometning  that  prevents 
the  unauthorized  access  of  information.  In  the  broadest 
sense,  one  may  include  as  protection  mechanisms  such  things 
as  walls,  patrol  dogs  and  cypher  locks.  More  specifically, 
tnough,  a  protection  mecnanism   for  a   computer   operating 

system  is  a  procedure,  implemented  in  software,  firmware  (if 
there  is   such   a   thing)   or  hardware,  that  prohibits  tne 
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access  of  objects  witttin  a  system  such  that  the  domain  of 
any  process  is  dominated  by  some  particular  dominance  domain 
inherently  established  by  the  protection  mechanisms. 


Figure  13.   Multics  Rings 

The  Multics  Ring  Mechanism  [2SJ  is  a  well  Known 
protection  mechanism  that  provides  an  excellent  example  for 
the  discussion  of  dominance  domains.  One  may  thins  of  these 
dominance  domains  as  a  set  of  concentric  rings  (illustrated 
in  figure  13),  each  numbered  in  increasing  order  from  tie 
inner-most  ring  or  Kernel.  The  Kernel  is  conventionally 
assigned  ring  number  zero. 
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The  Multics  Ring  Mechanism  determines  the  authorized 
access  of  a  subject  by  means  of  tne  current  ring  number  (r) 
that  specifies  the  dominance  domain.  Discrimination  among 
objects  is  by  means  of  a  ring  bracket.  The  ring  bracket  is  a 
three-tuple  (Rl,  R2,  R3 )  where  Rl ,  R2,  and  R3  are  ring 
numbers  and  Rl  must  be  numerically  less  tnan  or  equal  to  R2 
which  is  less  than  or  equal  to  R3.  Access  is  characterized 
by  tne  rules  illustrated  in  the  linear  access  grapn  snown  in 
figure  14. 


tRlng   0 


Write    (Modify) 


Execute  Call    (as    a   gate) 

JRif"  "~rSv  ~r1H 


Read  (Observe) 


Figure  14.   Multics  Ring  Mechanism  Linear  Access  Graph 

Consider  now  a  system  that  uses  tne  Multics  Ring 
Mechanism  and  discriminates  among  four  distinct  hierarchical 
rings  (0  tnru  3).  One  may  tnink  of  tne  domains  establisned 
by  this   system  as  AQ  ,  A1 ,  A2 ,  and   A3 .   Consider   tne 


rules  of  access  established  in  figure  14t  wnere  MA 


0 


is  tie 


objects  that  may  be  modified  by  a  process  in  domain  0.   Then 


MAQ  o*-     MA, 


MA. 


MA.  .    Likewise ,  0  A  Q 


OA. 


OA. 


OA_.   No  such  relationship  exists  for  execute  or 


call  (as  a  gate).  EA_  does  not  <*?  EA2  ,  as  R2  may  be  2  for 
some  object  X,  in  which  case  X  €  EA  but  X  f^  *&3  . 
Likewise  CA-  (the  Call  (as  a  gate)  domain  of  A  )  does  not 
°*  CA2  as  R3  may  be  zero,  for  example,   in  which  case,   Rl 
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and   R2  must   be   zero,   ruling   out   the   possibility   of 
successive  dominance  call-domains. 

Note  that  a  single  object  may  be  a  member  of  several 
dominance  domains.  Some  object  X,  with  rinff  brackets  (2,2,3), 
is  a  member  of  Oa0 ,  0AX,  3A2t  MA0  .  Eaq  ,  2&1  ,  Ea2  ,  and 
CA3.  Therefore,  X  €.  AQ ,  A,,  A2  and  A^.  This  concept 
can  be  confusing  as  an  object  is  a  distinct  entity  generally 
represented  by  a  single  imace. 

This  section  has  established  a  formal  definition  of 
domains  suitable  for  discussion  of  complex  domain  related 
issues.  Tne  notion  of  dominance  domains  was  introduced  and 
their  relationship  to  protection  mechanisms  established.  The 
Multics  Ring  Mechanism  provided  an  example  of  the  means  by 
which  one  may  evaluate  tne  dominance  domains  established  by 
a  protection  mechanism.  Having  formulaized  these  concepts, 
the  relationship  between  policy  and  mechanism  may  now  be 
investigated  in  an  organized  manner. 
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IV.   THE  ASSIGNMENT  TECHNIQUE 

This  section  introduces  a  mathematical  framework  for 
evaluating  the  relationship  between  non-discretionary 
security  policies  and  protection  mechanisms.  An  evaluation 
approach,  termed  "Tne  Assignment  Technique",  utilizes  the 
entity  -  relationship  model  in  establishing  an  assignment 
between  the  security  classes  of  information  establisned  by 
the  policy  constraints,  and  dominance  domains,  established 
by  the  properties  of  the  mecnanism.  The  assignment  tecnnique 
provides  a  theoretical  foundation  for  assessing  the 
sufficiency  of  an  access  control  mecnanism  with  respect  to  a 
well  formed  protection  policy. 

This  section  begins  with  a  general  discussion  of  tne 
meaning  of  "assignment".  It  then  proceeds  to  introduce  the 
assignment  tecnnique  in  a  general  form.  The  section 
concludes  wi tn  a  simplification  of  the  assignment  tecnnique 
made  possible  by  tne  lattice  nature  of  non-discretionary 
security  policies. 

A.   ASSIGNMENT 

Assignment  is  the  establishment  of  a  relationsnip 
between  two  entities  such  that  the  first  entity  is  "assigned 
to"  the  second  entity.  Matnematlcaliy ,  tne  term  assignment 
is  not  significant.  One  could  easily  have  said  that  entity  1 
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is  related  to  entity  2.  Intuitively,  however,  assignment   is, 
associated  witn   tne   connotation  "to  fix  autnoritati vely" . 
This   precisely  describes   the   manner   in   which   tnis 
relationship  is  establisned. 

Assignment  may   be   denoted   by   a  grapn  from  the  first 
entity  to  the  second  as  follows: 


is  assigned  to 


->  (ENTITY  2 


It  is  important  to  recognize  that  assignment  does  not 
alter  either  entity.  Assignment  is  merely  the  act  of 
associating  an  entity  or  set  of  entities  with  some  other 
entity  or  set  of  entities. 

Another  way  to  describe  assignment  is  in  terms  of  tne 
act  of  forming  a  tuple  (entity  1,  entity  2).  Additionally, 
one  may  thinfc  of  assignment  as  a  function  (i.e.,  "is 
assigned  to")  where  the  assignment  process  establishes  a 
mapping  between  two  otnerwise  disjoint  entities.  Regardless 
of  the  context  of  discussion  or  the  symbolism  used,  one  may 
sinply  thinfc  of  assignment  as  tne  act  of  associating  one 
thing  with  another. 

B.   THE  TECHNIQUE 

The  essence  of  the  assignment  technique  is  relatively 
simple.  First  of  all,  consider  the  nature  of  a  lattice 
security  policy.  Such  a  policy  partitions  tne  objects   of   a 
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system  into  a  lattice  of  equivalence  classes  labeled  by  the 
access  classes  as  discussed  in  section  II.  Eacn  equivalence 
class  can  be  thought  of  as  an  entity  that  may  be  subject  to 
assignment. 

Then  consider  a  mechanism,  which  establishes  a  lattice 
of  dominance  domains  as  discussed  in  section  III.  Each  of 
these  domains  can  also  be  thought  of  as  an  entity  that  may 
be  subject  to  assignment. 

Since  an  assignment  can  be  establisned  between  any  two 
entities,  one  can  ma&e  an  assignment  between  the  equivalence 
classes  established  by  a  lattice  security  policy  and  the 
dominance  domains  established  by  some  protection  mechanism. 
One  may  tnen  validate  that  (for  this  assignment)  tne 
mechanism  is  sufficient  to  support  this  policy.  This 
validation  is  made  by  examining  the  set  of  access  relations 
that  the  mechanism  permits,  and  testing  for  possible 
violations  of  the  policy. 

Tne   assignment   tecnnique   can    be   described   more 

systematically  as  follows: 

1)  Determine  if  tne  policy  is  a  lattice 
policy.  If  not,  the  assignment  technique  does  not 
apply. 

2)  Establish  the  set  of  equivalence  classes, 
{  e\ ,  e2 ♦  •••»  e^ ,  ...,  6p  >,  that  are 
associated  with  each  access  class. 

3)  Determine  tne  set  of  dominance  domains, 
{  Alf  A2  ,  ...,  A  ...,  A  }t  that  are 
established  by  tne  systems  protection  mechanism. 
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4)  Make  an  assignment  from  e,     to   A  . 

k  g 

5)  For  tnis  assignment,  examine  tne  access 
relations  permitted  by  tne  mecnanism,  testing  for 
possible  violations  of  tne  policy. 

6)  If  no  violations  can  exist,  tne  mecnanism 
is  sufficient  for  tne  policy  in  question. 


Step  4  of  tne  assignment  metnod  allows  for  considerable 
flexibility  in  the  manner  in  wnicn  assignments  can  be  made. 
Any  possible  mapping  from  equivalence  classes  to  dominance 
do-nains  may  be  considered.  Tnis  flexibility,  nowever, 
implies  considerable  effort  in  order  to  determine  tnat  a 
mechanism  is  not  sufficient  for  a  given  policy.  Fortunately, 
in  tnis  tnesls  one  is  specifically  dealing  witn  tne  security 
issue.  Because  of  this,  several  refinements  can  be  made  tnat 
greatly  simplify  this  tasK. 

C.   SIMPLE  ASSIGNMENT 

The  question  of  how  one  chooses  to  mate  assignments 
(i.e.,  the  cnoice  of  an  assignment  scneme)  may  seem 
relatively  complex  upon  first  inspection  of  the  assignment 
technique.  The  problem,  nowever,  becomes  almost  trivial  when 
dealing  witn  simple  non-discretionary  security  policies  as 
is  shown  by  the  following  arguments. 

First  of  all,  it  is  clear  tnat  tne  equivalence  classes 
(established  by  the  policy  constraints)  represent  distinct 
access  classes.  It  is  also  clear  tnat  tne  dominance  domains 
represent  distinct   sets   of   objects.   If   more   than   one 
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equivalence  class  were  assigned  to  tne  same  dominance 
domain,  then  there  is  nothing  in  tne  mechanism  to 
distinguish  between  tne  access  classes.  £ut  tne  policy  does 
draw  some  distinctions  Between  these  access  classes  (i.e., 
tnat  distinction  established  by  tne  definition  of  tne  access 
classes),  so  it  would  not  be  possible  to  enforce  tne  policy 
with  such  an  assignment.  All  such  assignments  can  be 
eliminated,  a  priori. 

On  the  other  hand,  if  one  equivalence  class  was  assigned 
to  more  than  one  dominance  domain,  tnen  some  distinction  is 
bein*  made  for  an  access  class  that  is  not  specified  in  the 
policy.  In  some  cases,  one  may  find  that  sucn  distinctions 
produce  violations  of  the  policy.  Although  other  cases  may 
not  do  so,  tnese  extra  dominance  domains  are  unnecessary, 
providing  distinctions  which  have  no  significance. 
Tnerefore,  tne  numDer  of  dominance  domains  of  interest 
established  by  the  mechanisms  should  be  equal  to  the  number 
of  access  classes  established  by  the  policies. 

One  may  attempt  to  argue  tnat  mere  may  exist  dominance 
domains  that  do  not  receive  an  assignment.  Such  domains, 
however,  must  be  either  empty  or  in  no  way  allow  for  an 
exception  to  the  enforcement  of  the  policy.  As  such,  one 
need  not  be  concerned  with  the  question  of  tneir  existence. 
One  need  only  concentrate  on  the  dominance  domains  for  which 
the  assignment  was  made. 
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Considering  assignment  as  a  function,  it  has  been 
established  that  tne  only  assignment  scnemes  of  interest  are 
bijective  (i.e.,  a  one  to  one  and  onto  relationship  between 
the  access  classes  and  the  dominance  domains  122]).  This 
provides  some  improvement,  but  one  is  still  faced  with  at 
least  pf  possible  assignment  schemes  to  evaluate  (where  p  is 
the  number  of  access  classes  established  by  tne  policy). 

One  may  eain  considerable  improvement,  however,  by  only 
attempting  to  validate  one  simple  mechanism  witn  respect  to 
one  simple  policy  at  a  time.  Furthermore,  the  Knowledge  of 
partially  ordered  sets  may  be  used  to  mate  our  assignments 
in  a  very  selective  manner.  This  is  done  by  first  requiring 
tnat  tne  lattice  for  tne  dominance  domains  of  Interest  that 
one  considers  for  assignment,  be  an  isomorphic  image  of  that 
for  the  equivalence  classes.  This  may  not  be  a  necessary 
condition,  however,  it  in  no  way  invalidates  the  results 
shown  (as  one  would  otherwise  be  dealing  with  an  isomorphic 
sub-image  established  by  the  necnanism),  and  it  is  neipful 
in  this  discussion. 

When  considering  the  isomorphic  ima^e  of  a  lattice,  the 
problem  of  assignment  is  reduced  to  a  question  of 
orientation.  One  may  either  assign  the  greatest  lower  bound 
of  tne  lattice  to  tne  greatest  lower  bound  of  tne  image,  or 
assign  the  greatest  lower  bound  of  the  lattice  to  the  least 
upper  bound  of  tne  image.  Any  other  assignment  would  not  be 
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acceptable   as   it  would  violate  the  ordering  or  the  lattice 

or  of  the  image . 

So  for  a  system  of  V  isomorphic  images  of  the   lattice 

established   by   the  policy,  one  need  only  consider  at  most, 

21c  assignment  schemes.  In  most   practical   cases,   when   the 

mechanism  establishes  isomorphic  images  which  are  identical 

in  their  access  control  properties  because   of   the   uniform 

nature  of  the  mechanism,  one  need  consider  only  2  assignment 

schemes. 

The  Simple  Assignment  Theorem  :  For  any  simple 
lattice  policy  and  an  isomorphic  image  established 
by  some  protection  mechanism,  no  more  than  two 
assignment  schemes  are  necessary  to  validate  the 
sufficiency  of  tne  mecnanism  to  enforce  the 
policy. 

Proof  Slcetcn  :  Tne  proof  proceeds  by  snowing 
that  two  assignment  schemes  are  reasonable  and 
that  all  others  are  not. 

1)  Mate  assignments  starting  from  tne  greatest 
lower  bound  (GLB)  of  the  lattice  to  the  GLB  of  the 
isomorphic  image.  Tnen  assign  every  reachable 
access  class  (i.e.,  those  of  unit  distance)  to  a 
reachable  dominance  domain  in  the  isomorphic 
image.  Next  assign  all  reachable  access  classes 
from  those  just  assigned  (which  are  not  already 
assigned)  to  a  corresponding  reachable  dominance 
domain.  Proceed  in  this  fashion  until  all  access 
classes  nave  been  assigned.  An  assignment  sucn  as 
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tnat  snown  in  figure  15  will  result,  wnere  tne  L'JE 
is  assiened  to  tne  LUB,  A  is  assigned  to  A',  E  is 
assigned  to  B't  and  so  t'ortn. 

This  assi?nment  is  a  valid  assignment  in  that 
an  assignment  can  be  Tiaae  from  tne  access  classes 
to  tne  dominance  domains  tnat  is  not  inherently 
incorrect  and  tnerefore  is  worthy  of 
consideration.  Tnis  does  not  mean  tnat  tne 
protection  mecnanism  is  sufficient  for  tnis 
assignment.  It  only  implies  tnat  sucn  an 
assignment  scneme  is  wortny  of  consideration. 


ACCESS  CLASSES 


DOMINANCE  DOMAINS 


Figure  15.   GIB  to  GLB  Assignment 


2)  Now  consider  a  second  practical  assignment. 
This  assignment  starts  from  tne  SLB  of  tne  lattice 
mating  an  assignment  to  tne  LUB  of  tne  isomorpnic 
image  and  proceeding  as  in  the  first  assignment 
scheme.  The  resulting  assignment  is  illustrated  in 
figure  16  wnere  tne  LOB  is  assigned  to  tne  GIB,  A 
is  assisned  to  D',  D  is  assigned  to  A',  and  so 
forth. 
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ACCESS  CLASSES 


DOMINANCE  DOMAINS 


Figure  16.   SLB  to  LUB  Assignment. 

It  is  important  to  note  tnat  if  tne  lattice 
structure  is  not  uniform,  i.e.,  inverting  tne 
lattice  rfouli  not  produce  tne  same  image,  tnen 
only  one  of  tne  two  aforementioned  assignment 
scnemes  will  De  successful.  THis  limitation  occurs 
because  one  encounters  some  set  of  reachable 
access  classes  luring  assignment  tnat  nave  no 
corresponding  reachable  dominance  domains. 
However,  for  any  lattice  structure,  uniform  or 
otherwise,  there  will  always  be  one  assignment 
scnene  to  an  isomorphic  image  tnat  is  worthy  of 
consideration.  This  leads  us  to  the  following 
corollary. 


Corollary  1.  For  any  lattice  policy  and 
an  isomorphic  image  established  by  some 
protection  mechanism,  there  exists  at 
least  one  valid  assignment  scneme. 

Proof  Sfcetch  (Corollary  1)  :  The  proof 
is  trivial  from  the  definition  of  an 
isomorphic  image.  If  a  lattice  has  an 
isomorphic  image,  tnen  at  least  one 
ordering  of  nodes  in  tne  image  is 
identical  to  the  ordering  of   nodes   in 
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tne  lattice,  therefore,  tnis  ordering  is 
wortny  of  consideration. 

3)   Now   consider   tne   assignment   of  the  GL£ 

access  class  to  any  dominance   domain   otner   than 

tne   LUB   or   tne   GLB.  If  tnis  is  done*  then  some 

otner  access  class  must  be   assigned   to   tne   LUB 

dominance   domain   and   still  anotner  access  class 

:nust  be  assigned  to  tne  GLB  dominance  domain.   But 

if    the   isomorphic   image   is   to   maintain   the 

ordering  of  tne  access  classes,  tnen  tnere   exists 

some   ordering  which   is  not  valid  because  either 

tne  GLB  or  tne  LUB  of  tne  isomorpnic  image   is   to 

be   considered   less   than   tne  GLB  (in  the  image) 

wnicn  must   be   tne   least   element   (viz.,   least 

sensitive)   according   to   the   poliry.  Therefore, 

such  an  assignment  can  never  be  valid.  Tnus  one  is 

reduced   to   tne   tas£   of   considering   only   two 

possible  assignment  schemes  of  interest. 

One  can  furtner  simplify  the  assignment  technique  by 
combining  steps  4  and  b.  This  is  accomplished  by  maKin?.  an 
assignment  and  examining  all  access  relations  producible 
immediantly.  If  an  access  relation  is  not  valid,  one  can 
quickly  determine  that  tne  assignment  scheme  in  use  will  not 
validate  the  sufficiency  of  the  mechanism. 

Wnen  one  is  dealing  with  more  complex  lattice 
structures,  one  is  faced   with   two   alternatives.   One   can 
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either  validate  tne  sufficiency  of  tne  mechanism  for  eacn 
sub-policy,  es tablishing  tnat  if  each  sub-policy  is 
enforced,  then  the  complex  policy  is  enforced,  or  one  may 
choose  to  validate  the  complex  policy  by  a  straight  forward 
assignment.  rfhen  using  a  straight  forward  assignment 
approach,  one  must  remember  that  tne  Simple  Assignment 
Theorem  may  not  apply.  This  is  of  no  particular  consequence 
when  validating  a  protection  mecnanism  designed  for  a 
particular  policy  where  the  assignments  are  chosen 
carefully.  Eowever,  establishing  the  insufficiency  of  an 
arbitrary  mecnanism  may  require  considerably  more  effort. 

The  basic  principles  associated  with  the  assignment 
technique  nave  been  presented  in  this  section.  One  may  now 
consider  some  simple  examples  that  illustrate  the  usefulness 
of  assignment. 
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V.   MECHANISM  SUFFICIENCY  VALIDATION  J3Y  ASSIGNMENT 

One  of  the  most  practical  uses  for  the  assignment 
technique  is  sufficiency  validation  of  protection  mecnanisms 
(i.e.,  validation  of  their  ability  to  enforce  security 
policies)  [4j  .  In  contrast  to  other  validation  techniques 
[lltl7Jf  ttie  assignment  technique  presents  a  metnod  wnose 
mathematical  model  (i.e.,  the  entity-relationship  model)  is 
based  upon  the  nature  of  security  itself,  rather  than  otner 
methods  whicft  adapt  the  nature  of  security  into  a  form 
designed  to  mesh  vita  the  prescribed  format  of  some  well 
Known  mathematical  model.  This  section  discusses  mechanism 
sufficiency  validation  by  assignment  for  several  well  Known 
linear  non-discretionary  security  policies.  Although  the 
principles  discussed  in  this  section  apply  for  all  lattice 
security  policies,  only  linear  lattice  policies  are 
discussed  in  tnis  section  as  tney  provide  a  sufficient 
foundation  for  the  discussion  of  any  lattice  policy  and  are 
more  clearly  illustrated  in  this  context. 

A.   MULTICS  RING  MECHANISM  ASSIGNMENTS 

The  question  of  the  sufficiency  of  tne  Multlcs  Ring 
Mechanism  for  enforcement  of  the  basic  National  Security 
policy  was  tne  initial  problem  tnat  prompted  the  current 
research  effort  and  led  to  the  formulation  of  tne  assignment 
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technique.  It  is  appropriate  then,  that  this  analysis  be 
presented  as  an  introductory  application  of  simple 
assignment. 

1.   Compromise  Policy 

As  stated  previously  in  section  II,  the  basic 
National  Security  policy  is  a  simple  lattice  security 
policy.  Figure  13  illustrates  this  policy. 

The  dominance  domains  of  the  Multics  Ring  Mechanism 
are  most  frequently  shown  as  concentric  rings  numbered  in 
increasing  integer  order  from  the  innermost  ring  or  the 
fcernel.  The  security  kernel  is  generally  assigned  ring 
number  0.  For  simplicity,  only  a  system  with  rings  0  thru  3 
is  shown  in  this  analysis.  Assignment  to  other  ring  numbers 
(such  as  2  thru  5  or  4  thru  7)  will  produce  similar  results 
because  of  the  uniform  nature  of  the  Multics  Ring  Mechanism. 

Consider  as  the  first  assignment  scheme,  the 
assignment  of  the  TOP  SECRET  access  class  (the  least  upper 
bound  of  the  policy)  to  ring  0  (the  least  upper  bound  of  the 
dominance  domains).  The  assignment  produced  is  illustrated 
in  figure  17. 

Next,  according  the  assignment  technique,  one  must 
examine  the  access  relations  permitted  by  the  mecnanism  and 
test  for  possible  violations  of  the  policy.  In  order  to  do 
sof  one  must  first  examine  the  nature  of  the  Multics  Ring 
Mechanism  more  closely.  A  detailed  discussion  is  given  by 
Schroeder   [27] ,   however,   a  simple  explanation   of    the 
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pertinent  details  as  used  in  this  discussion  is  provided  for 
those  readers  not  otherwise  familiar  with  Multics. 


Observe) 


{Modify 


is  assigned  to 


is  assigned  to 


(  Ring  0  J 
Ring  1 


Observe) 


{Modify 


is  assigned  to 


Ring  2 


Observe) 


{Modify 


is  assigned  to 


Rin?  3 


Figure  17.   Basic  National  Security  Assignment  1. 

The  Multics  Ring  Mechanism  determines  the  autnorized 
access  of  a  process  by  means  of  the  current  ring  number  (r). 
Thus  a  process  wnicn  is  executing  in  ring  number  1  would 
need  to  be  cleared  for  at  least  SECRET  information  according 
to  this  assignment  scneme. 

The  Multics  Ring  Mechanism  discriminates  among 
objects  by  means  of  a  ring  bracket.  The  ring  bracfcet  is  a 
three-tuple  (  Rl,  R2 ,  R3)  where  Rl,  R2  and  R3  are  ring 
numbers  and  Rl  <LR2.£.R3.  Access  to  objects  is  restricted 
such  that  the  current  ring  of  execution  must  be  less  than  or 
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equal  to  R2  to  observe  information  and  less  tfian  or  equal  to 

Rl  to  modify  information.  Figure  IS  snows  characteristics  of 

tne  rins  brackets  botb  in  terms  of  the  access  modes  used  in 
tnis  discussion  and  tne  access  modes  used  in  Multics. 

Execute  (Observe) 

•  .Ring  0 'Rl,  R2' I 

1        tfrite  (Modify)      | 

Read  (Observe) 

Figure  18.   Multics  Ring  Mechanism. 

Continuing  now  with  tne  examination  of  access 
relations,  consider  an  object  that  is  classified  as  SECRET. 
Sucn  an  object  must  be  assigned  a  ring  bracket  sucn  tnat  it 
may  be  observed  by  processes  in  ring  0  and  ring  1  only.  R2 
must  tnerefore  be  1.  This  presents  a  problem.  No  matter  what 
value  one  may  choose  for  Rl ,  a  contradiction  occurs.  If  Rl 
is  0  or  1  tnen  TOP  SECRET  processes  may  modify  SECRET  files 
violating  the  Confinement  Property.  If  Rl  is  greater  tnan  1, 
tne  restrictions  of  tne  ring  mecnanism  would  be  violated 
(viz.,  Rl  >  R2).  Tnerefore,  one  can  conclude  tnat  this 
assignment  is  not  acceptable. 

Consider  now  tne  only  other  potential  assignment 
scheme  where  tne  greatest  lower  bound  of  the  lattice  (the 
UNCLASSIFIED  access  class)  is  assigned  to  ring  0.  This 
assignment  is  illustrated  in  figure  19. 

One  may  now  attempt  to  assign  ring  brackets  to  an 
object  classified  SECRET.  A  problem  occurs  immediately.  One 
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wants  processes  executing  in  ring  2  to  observe  SECRET 
objects,  but  tnen  a  process  in  Tins  0  (i.e.,  an  UNCLASSIFIED 
process),  will  also  be  able  to  observe  tne  object.  Tie 
Simple  Security  Condition  cannot  be  enforced  witn  tnis 
assignment,  so  tie  assignment  scneme  is  not  feasible. 


Observe) 


{Modify 


Observe} 


Observe} 


is  assigned  to 


Ring  3 


is  assigned  to 


Ring  2 


{Modify 


is  assigned  to 


Ring  1 


{Modify 


is  assigned  to 


Figure  19.    Basic  National  Security  Assignment  2. 

Since  neither  of  tnese  assignments  are  acceptable, 
and  snifting  tne  ring  assignments  numerically  would  yield 
similar  results,  one  can  see  tbat  no  assignment  will  be 
acceptable.  Therefore,  the  Multics  Ring  Mecnanism  is  not 
sufficient  to  enforce  the  basic  National  Security  policy  for 
compromise. 
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2.      Subversion   Policy 

i  i  V 


The  basic  National  Integrity  policy  L21J  is  tne  dual 
of  the  basic  National  Security  policy.  Wnereas  tne  security 
policy  is  concerned  with  the  unautnorizea  .  observation  of 
information  or  compromise,  tne  integrity  policy  is  concerned 
with  the  unauthorized  modification  of  information  or 
subversion  as  discussed  in  section  II. 

Consider  first  tne  assignment  of  the  TOP  SECRET 
access  class  (the  least  upper  bound  for  the  lattice 
established  by  the  policy)  to  Ring  0  (the  least  upper  bound 
for  the  dominance  domains  established  by  the  mechanism).  The 
assignment  produced  is  shown  in  figure  20. 


TOP  SECRET 
Modify) 


is  assigned  to 
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Modify) 


is  assigned  to 
{Observe 
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is  assigned  to 
{Observe 


is  assigned  to 


Ring  3 


Figure  20.   Basic  National  Integrity  Assignment  1. 
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One  nay  now  examine  tne  access  relations  wnicn  tne 
Multics  Ring  Mecnanism  will  permit  (as  snown  in  figure  19) 
and  test  for  possible  violations  of  tne  policy.  In  so  doing, 
one  encounters  violations  almost  immediently.  One  wishes  to 
nave  a  process  executing  in  Ring  1  (i.e.,  a  SECRET  process), 
for  example,  to  be  able  to  observe  TOP  SECRET  objects  in 
Ring  0,  but  tne  mecnanism  pronibits  tnis  observation. 
Additionally,  a  SECRET  process  could  observe  CONFIDENTIAL 
information  violating  tne  Integrity  Confinement  Property. 
Therefore,  this  assignment  scheme  is  not  feasible. 


is  assigned  to 
{Observe 

"is  assigned  to 
{Observe 

"is  assigned  to 
{Observe 

"is  assigned  to 


Ring  3 


Ring  2 


Ring  1 


Figure  21.   Basic  National  Integrity  Assignment  2. 

Consider  now  the   only   other   potential  assignment 
scneme   (viz.,   according   to  tne  Simple  Assignment  Theorem) 
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wnere  trie  TOP  SECRET  equivalence  class  is  assigned   to   Rim? 
3.  This  assignment  scneme  is  illustrated  in  figure  21. 

Examining  tnis  assignment,  consider  an  object  tnat 
is  classified  as  SECRET.  Sucn  an  object  must  be  assigned  a 
ring  bracket  sucn  tnat  it  may  be  observed  by  processes  in 
Ring  0,  Ring  1  and  Ring  2  only,  so  R2  must  be  assigned  2. 
.But  if  R2  is  2,  one  is  faced  with  a  contradiction  in  the 
assignment  of  Rl.  If  Rl  is  assigned  0,  1  or  2,  then  a 
violation  of  tne  Simple  Integrity  Condition  occurs  because 
UNCLASSIFIED  subjects  may  then  modify  SECRET  objects.  If  Rl 
is  assigned  3.  tne  Ring  Bracket  constraints  are  violated. 
Therefore,  this  assignment  scheme  fails  to  provide  an 
assignment  where  the  protection  mechanism  can  enforce  this 
policy. 

According  to  the  Simple  Assignment  Theorem,  there 
are  no  other  assignments  wortny  of  consideration.  Therefore, 
the  Multics  Ring  Mechanism  is  not  sufficient  to  enforce  this 
policy  either. 

So  far,  it  has  been  shown  that  the  Multics  ^ing 
Mechanism  is  not  sufficient  to  enforce  the  basic  National 
Security  policy  nor  the  basic  National  Integrity  policy. 
However,  a  Multics  Security  Kernel  has  been  designed  [28,29J 
that  is  sufficient  to  support  both  of  these  policies.  This 
may  seem  to  be  a  contradiction  but  it  is  not.  Tne  confusion 
is  dissipated  when  one  asfcs  the  question,  "Wnat  form  of 
policy  does  the  Multics  Rins   Mechanism  support?" 
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3.   Program  Integrity  Policy 

The  general  form  of  Program  Integrity  policies  was 
introduced  in  section  II.  Consider  now  tne  specific  program 
integrity  policy  shown  in  figure  22. 


Max 


,    Execute , 

lPIi  Min' 


Modify 


Read 
Figure  22.   A  Program  Integrity  Policy. 

According  to  this  policy,  entities  are  partitioned 
into  one  of  four  access  classes  designated  as  User, 
Supervisor,  Qtility  or  Kernel.  The  sensitivity  of  these 
access  classes  is  specified  as  :  Kernel  >  Supervisor  > 
Utility  >  User.  An  assignment  to  a  Multics  ring  structure  is 
made  as  shown  in  figure  23. 

Recalling  tne  cnaracteristi cs  of  ring  brackets  snown 
in  figure  IB,  "Max"  is  designated  as  Ring  0,  the  program 
integrity  access  class  (PI)  as  Rl  and  "Min"  as  R2.  One  may 
note  that  for  this  policy  any  choice  for  R2  greater  than  or 
equal  to  Rl  will  do.  Tnis  analysis,  nowever,  nas  fixed  R2  at 
3. 

According  to  tne  assignment  tecnnique,  one  must  now 
examine  the  access  relations  permitted  by  the  mecnanism  and 
test  for  possible  violations  of  tne  policy.  Unliire  previous 
examples,  where  the  mechanism  was  obviously  not  sufficient 
to  support  the  policy  (i.e.,  only  a  single   counter-example 
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was  necessary)  this  example  examines  a  policy  tnat  is  lively 
to  be  supported  by  the  Multics  Ring  Mechanism.  Knowing  this, 
it  seems  appropriate  to  present  a  more  careful  approacn  for 
the  validation  of  this  assignment. 
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Modify} 
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Figure  23.   Program  Integrity  Assignment  1. 

For  simplicity,  one  may  refer  to  eQ  {tne  first 
equivalence  class)  as  Kernel  (i.e.,  tne  access  class  tnat 
labels  this  equivalence  class  of  subjects  and  objects),  e 
as  Supervisor,  e  as  Utility  and  e  as  User.  One  may  also 
refer  to  AQ  (the  first  dominance  domain  established  by  tne 
Multics  Ring  Mechanism)  as  Ring  0,  A,  as  Ring  1,  A2  as 
Ring  2  and  A3  as  Ring  3.   The  assignment  scneme  consists  of 
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assigning  e  to  a0  (Kernel  to  Ring  0),  e  to  a,  (Supervisor 
to  Rine  1),  e2  to  a2  (Utility  to  Rine  2),  e3  to  a3  (User 
to  Ring  3).  One  can  now  evaluate  the  access  relations 
permitted  by  tne  Multics  Ring  Mechanism  and  compare  them 
witn  tne  policy. 

Examining  tne  read  access  first,  one  notes  that  tne 
Multics  Ring  Mechanism  provides  no  discrimination  for  read 
access  since  R2  is  fixed  at  3  for  ail  objects.  Thus  subjects 
in  AQ  ,  Alf  A2  or  a3  nay  read  objects  in  aq  ,  A,  (  A2 
and  A...  This  corresponds  with  tne  access  rights  of  tne 
policy  wnicn  states  tnat  subjects  in  e  ,  e  ,  e  or  e  may 
read  objects  in  e  ,  e  ,  e  and  e  .  Therefore,  tfte  mechanism 
is  sufficient  witn  respect  to  tne  read  access  relations. 

Next,  examining  the  modify  access  relations  one  may 
observe  that  MAQ  o*  i^  oc  ma2  o*.  Ma3  .  Thus  a  subject 
in  AQ  may  modify  objects  in  AQ  ,  A,,  A2  or  A-  .  This 
corresponds  to  tne  access  rignts  of  the  Kernel  access  class 
in  that  a  subject  in  e  may  modify  objects  in  e  ,  e  ,  e  and 
e_  .  Examining  A,,  one  observes  tnat  a  subject  in  a,  may 
modify  objects  in  a,  »  A9  or  a7  out  not  in  An •  This 
corresponds  with  tne  access  rignts  of  tne  Supervisor  access 
class  in  that  a  subject  in  e  may  modify  objects  in  e  ,  e 
and  e3  but  not  in  e  .  Examining  A  ,  one  observes  that  a 
subject  in  A2  may  modify  objects  in  A2  or  A3  but  not  in 
AQ  or  A,.  This  corresponds  with  the  access  rights  of 
the  Utility  access  class  in  tnat  a  subject   in  e  may  modify 
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objects  in  e  or  e  but  not  in  e  or  e  .  Finally, 
examining  a  ,  one  observes  that  a  subject  in  a  may  only 
modify  objects  in  A3«  This  corresponds  with  the  access 
rights  of  the  User  access  class  in  tnat  a  subject  in  e. 
may  only  modify  objects  in  e3.  Therefore,  the  Multics 
Ring  Mecnanism  is  sufficient  to  support  this  policy  with 
respect  to  modify  access  relations. 

Next,  examining  the  execute  access  relations  one  may 
observe  that  XA3  ~*  XA2  *»*  1A±  <=><  XAQ.  This  is  Just 
the  inverse  of  the  modify  access  relations.  Thus  a  subject 
in  A3  may  execute  objects  in  AQ,  A,,  A2  or  A.,.  This 
corresponds  to  the  access  rights  of  the  User  access  class  in 
that  a  subject  in  e3  may  execute  objects  in  eQ,  e,,  e2  and 
e3.  Examining  A2,  one  observes  that  a  subject  in  A  may 
execute  objects  in  AQ,  A.,  or  A2  but  not  in  A  .  This 
corresponds  with  the  access  rights  of  the  Utility  access- 
class  in  that  a  subject  in  e2  may  execute  objects  in  en  ,  e.. 
and  e2  but  not  in  e3.  Examining  A,  ,  one  observes  that  a 
subject  in  A1  may  execute  objects  in  AQ  or  A,  but  not 
in  A2  or  A3.  This  corresponds  with  the  access  rights 
of  the  Supervisor  access  class  in  tnat  a  subject  in  e,  may 
execute  objects  in  eQ  or  e-,  but  not  in  e2  or  e3 . 
Finally,  examining  AQ ,  one  observes  that  a  subject  in  AQ 
may  only  execute  objects  in  AQ .  This  corresponds  with  the 
access  rights  of  the  Kernel  access  class  in  that  a  subject 
in   eQ   may  only  execute   objects   in  en  .   Therefore,   tbe 
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Multics  Ring  Mechanism  is  sufficient  to  support   tnis  policy 
with  respect  to  execute  access  relations. 

So  one  may  observe  mat  for  eacn  of  tne  access  modes 
(read,  modify  and  execute),  tne  Multics  Ring  Mechanism  is 
sufficient  to  enforce  tne  policy.  Therefore,  for  tnis 
assignment,  no  violations  are  possible,  thus  proving*  that 
tne  Multics  Ring  Mecnanism  is  sufficient  to  support  tnis 
Program  Integrity  policy. 

B.   OTHER  RING  MECHANISMS 

The  Multics  Ring  Mecnanism  is  by  no  means  tne  only  form 
of  Ring:  Mechanism.  By  altering-  the  requirements  of  the  Ring- 
Brackets  and  tne  need  for  a  Gate  Keeper,  one  can  contemplate 
adapting  the  rine  mechanisms  to  meet  other  simple 
hierarchical  policies. 

Consider  using  the  assignment  shown  in  figure  17,  but 
altering  tne  means  of  discrimination  among  objects  such  mat 
the  Ring  Bracfcet  is  a  singleton  (Rl).  Following  the  rules 
shown  in  figure  24,  one  can  adapt  tnis  ring  mechanism  to 
enforce  the  basic  National  Security  policy. 


,    Modify 

>  KERNEL IR1|  MAX 

Observe 


Figure  24.   Security  Rings. 
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Similary,  figure  25  snows  the  rules  necessary  for  the 
same  assignment  as  snown  in  figure  20  to  adapt  tnis  ring 
mechanism  to  meet  tne  basic  National  Integrity  policy. 

Observe 

{KERNEL *Rlj  MAX' 

Modify 

Figure  25.   Integrity  Rings. 

To  be  sure,  tnese  brief  suggestions  do  not  completely 
characterize  a  practical  protection  mechanism.  However,  it 
appears  tnat  ring  mechanisms  are  adaptable  for  tne 
enforcement  of  various  simple  hierarchical  policies. 

C.   CAPABILITY  MECHANISMS 

Considerable  effort  is  currently  underway  to  provide 
"Provably  Secure  Operating  System"  based  upon  the  capability 
mechanism  [30,31].  It  is  important  to  examine  what  form  of 
protection  capaoilities  actually  provide. 

Capability  mechanisms  primarily  establish  two  dominance 
domains  tnat  are  enforced  by  tnis  system  hardware  mechanism. 
One  domain  consists  of  capabilities,  and  the  other  is 
objects  tnat  are  not  capabilities  such  as  segments  and 
directories.  A  process  talces  no  note  of  these  dominance 
domains,  however,  because  all  processes  have  access  to 
capabilities  as  well  as  other  types  of  objects.  So  with 
respect  to  a  process,  the  capability  mecnanism  provides  no 
inherent  partitioning  of  tne   system  entities   at  all.   In 
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fact,  in  trying  to  determine  tne  structure  of  dominance 
domains  for  non-capability  objects,  one  encounters  a 
veritable  "spaghetti  towl"  of  domains,  devoid  of  any 
innerent,  unifying  structure.  Thus  a  capability  mechanism  is 
of  itself  not  sufficient  for  the  enforcement  of  any 
non-discretionary  security  policy.  Enforcement  of 
non-discretionary  security  policies  (i.e.,  those  of  primary 
interest  to  National  Defense)  must  be  accomplished  by  some 
otner  add-on  mechanism. 

This  is  not  to  say  that  a  capability  mechanism  is  not 
useful.  For  example,  the  mechanism  can  protect  a  security 
Kernel  in  much  tne  same  way  as  rings  protect  tne  Kernel  in 
the  Multics  design. 

The  usefulness  of  the  assignment  technique  in  validating 
the  suitability  of  a  protection  mechanism  to  enforce  a 
security  policy  has  been  examined  in  this  section.  The 
validity  of  the  assignment  technique  has  been  estabisned. 
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VI.   CONCLUSION 

This  research  nas  explored  the  foundations  of 
non-discretionary  security,  discovering  an  effective 
methodology  for  assessing  tne  sufficiency  of  a  protection 
mechanism  to  enforce  a  non-discretionary  security  policy.  By 
formalizing  tne  notion  of  a  domain  [6,7J  ,  and  using  a  formal 
notion  of  non-discretionary  security  [3],  the  inseparable 
nature  of  protection  mecnanisms  and  security  policies  has 
been  established.  This  section  considers  some  future 
directions  for  research  and  summarizes  the  principle 
findings  of  the  author. 

A.   FUTURE  DIRECTIONS 

Although  this  author's  investigation  has  provided  some 
structure  to  the  complex  nature  of  security,  considerable 
researcn  is  still  needed.  The  relationsnip  between 
protection  mechanisms  and  other  operating  systems  mechanisms 
is  not  clear.  Sucn  issues  as  seriaii zabili ty , 
synchronization  and  distributed  processing  may  add  new 
dimensions  to  tne  meaning  of  protection.  Fundamental 
limitations  regarding  implementation  details  remain  unknown. 

Additionally,  one  can  consider  tne  formalization  of 
policy  specifications  in  general.  Can  the  enforcement  of  any 
policies   other   than  lattice  policies  be  evaluated?  Can  all 
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enforceable  policies  be  represented,  in  some  common  form  such 
as  a  lattice? 

One  of  tne  most  difficult  problems  in  actually  enforcing 
any  security  policy  is  tne  maintenance  of  unique 
non-forgeabie  attributes  [oj  associated  witn  tne  subjects 
and  objects.  A  mechanism  for  maintaining  the  uniqueness  of 
tnese  attributes  may  be  called  an  "isolation  mecnanism" 
because  it  isolates  those  subjects  that  may  access  these 
attributes  from  tnose  tnat  may  not.  This  does  not  prevent 
sharing  of  objects  but  simply  provides  a  means  of  isolating 
tnese  attributes  from  general  unprotected  usage.  Both  tne 
capability  mecnanism  [30,31]  and  the  notion  of  a  ?ate 
(mecnanism)  [3,28J  appear  to  be  isolation  mecnanisms.  A 
comprehensive  study  of  tnis  problem  is  beyond  the  scope  of 
this  discussion.  However,  a  few  observations  concerning 
isolation  noted  during  this  research  are  provided. 

Tne  fundamental  principles  upon  wnicn  an  isolation 
mechanism  must  rely  is  the  notion  of  a  segment  (i.e.,  an 
atomic  unit  of  information  storage  for  wnicn  tne  access 
class  is  identified)  and  the  tranquillity  principle  (i.e., 
the  notion  tnat  tne  access  class  for  a  subject  or  an  object 
does  not  caange  during  the  course  of  computations)  [17J  .  If 
these  two  principles  are  not  enforced,  it  is  not  clear  now 
one  may  evaluate  the  enforcement  of  any  non-discretionary 
security  policy. 
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Tne  tranquillity  principle  does  not  strictly  apply  to 
processes.  In  Multics,  for  example,  processes  had  several 
domains  of  execution.  However,  since  a  suDject  is  defined  as 
a  process-domain  pair,  one  mignt  at  first  suspect  tnat  a 
process  executing  in  multiple  domains  does  not  present  a 
security  problem.  Tnis  is  not  always  tne  case,  particularly 
when  dealing  with  policies  that  attempt  to  limit  tne 
information  flow  [13J . 

When  attempting  to  enforce  tne  National  Security  Policy 
in  a  multi-user,  multi-process  environment,  wnere  a  process 
executes  in  a  sequential  fashion  (i.e.,  the  process  is 
serializabie)  one  can  do  no  better  tnan  to  allow  a  process 
to  proceed  to  its  "high  water  mark:"  and  then  terminate  at 
that  level.  Any  attempt  to  revert  to  a  less  sensitive  access 
class  will  result  in  a  potential  compromise.  For  example, 
consider  the  compromise  technique  shown  in  figure  26. 

In  this  example,  a  malicious  agent  utilizes  the  feature 
of  sequential  processes  and  the  basic  PV  synchronization 
mecnanism  [33]  to  take  tne  "info"  in  Dominance  Domain  2  and 
copy  it  into  Dominance  Domain  1.  In  order  to  do  so,  the 
agent  calls  procedures  placed  in  the  "High"  domain  by 
subversion  [3],  relyine  only  upon  one  process  (i.e.,  PROCESS 
0  or  PROCESS  1)  to  return,  thus  providing  the  information  in 
binary  form  to  tne  "Low"  domain.  Thus  by  serialization  and 
process  synchronization  alone,  tne  isolation  of  the 
dominance  domains  has  been  compromised. 
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Figure   26.     Serialization   Problem. 
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Note  tnat  were  tne  processes  to  act  independently  in 
eacn  dominance  domain  (i.e.,  processes  are  seriaiizabie  only 
witn  respect  to  a  given  dominance  domain  or  syncnroni zation 
between  two  processes  is  not  possible)  this  compromise  could 
not  occur.  In  general,  tnis  example  snows  tnat 
syncbronization  of  processes,  serialization  of  processes  and 
secure  computations  are  fundamentally  related  in  some 
fasnion.  Tne  exact  nature  of  tnis  reiationsnip  is  not  clear. 

B.   RESULTS 

Tne  assignment  tecnnique  nas  been  snown  to  be  a  useful 
method  for  validating  tne  sufficiency  of  a  protection 
mechanism  to  enforce  non-discretionary  security  policies. 
This  method  provides  considerable  insight  into  the  nature  of 
access  control.  One  may  observe  tnat  non-discretionary 
security  is  dependent  only  upon  tne  dominance  domains 
established  by  tne  systems  mecnanisms  and  tneir  associated 
permissible  access  relations.  The  nature  of  tne  computation 
is  of  no  concern. 

Any  non-discretionary  security  policy  for  whicn  tne 
access  classes  and  access  relations  can  be  enumerated,  can 
be  enforced  in  a  theoretical  sense.  Actual  implementation, 
however,  is  dependent  upon  the  systems'  isolation  mecnanism. 
No  policy  can  be  enforced,  in  a  practical  sense,  unless  tne 
system  can  maintain  unique  non-f orgeable  attributes. 
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Protection  mecnanisms  innerently  mirror  tne  policies 
that  they  enforce.  Non-discretionary  Security  policies  form 
a  lattice  of  access  classes  tnat  may  be  mapped  to  an 
isomorphic  image  of  dominance  domains,  innerently 
established  by  the  protection  mechanism.  Since  this  has  been 
shown,  one  need  not  illustrate  separate  lattices  for  both 
policy  and  mechanism.  One  unified  description  for  both  the 
lattice  policy  and  its  image  established  by  the  protection 
mechanism  is  sufficient  for  general  systems  design 
considerations . 

One  may  also  consider  approaching  tne  assignment 
technique  from  the  mechanism  point  of  view.  The  question 
then  becomes,  "Given  some  general  Protection  Mecnanism,  what 
form  of  policies  will  it  support?"  An  absolute  answer  to 
this   question   is,   in  general,  not  available.  However,  one 

can  make  an  evaluation  for  tnose  policies  that  are  of 
current  interest.  Thus ,  tne  assignment  tecnnique  gives  one  a 
forum  in  which  to  consider  the  usefulness  of  protection 
mechanisms  for  specific  policies  of  interest. 

"Uniform  protection  mecnanisms,"  i.e.,  those  mechanisms 
forming  lattice  structures  of  dominance  domains  wnere  tne 
access  relations  between  any  two  antisymmetric  dominance 
domains  are  identical,  may  be  represented  by  linear  access 
graphs  in  the  same  manner  as  a  policy.  Wnen  the  linear 
access  srraph  for  the  policy  is  similar  to  the  linear  access 
grapn  for  the  mechanism,  one  can  see  that   for  a   carefully 
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chosen  assignment  scfieme,  tne  protection  mecnanisn  will 
enforce  tne  security  policy. 

One  nay  consiier  tne  development  cf  a  taxonomy  of 
uniform  protection  mecnanisms  cased  upon  tne  nature  of  tne 
access  control  tnat  eacn  enforces.  Sucn  a  taxonomy  is  beyond 
tne  scope  of  this  discussion,  however,  tne  linear  access 
graphs  illustrated  tnrougnout  tnis  text  may  be  neipfui  in 
initiating  sucn  an  effort. 

The  protection  provided  by  tne  Multics  Ring  Mecnanism 
appears  to  be  precisely  the  issue  tnat  Wuif,  Jones  and  tne 
otner  designers  of  tne  "HYDRA"  system  were  attempting  to 
understand  [1SJ .  They  introduce  their  discussion  by  first 
saying  : 

"Protection  is,  in  our  view,  a  mechanism."  [18 J 

Their  discussion  tnen  proceeds  to  make  tne  following 
general  statement  relative  to  the  Multics  rings: 


Our  rejection  of  nlerarcnical  system 
structures  and  especially  ones  which  employ  a 
single  nlerarcnical  relation  for  all  aspects  of 
system  interaction,  is  also,  in  part,  a 
consequence  of  the  distinction  between  protection 
and  security.  A  failure  to  distinguish  tnese 
issues  coupled  with  a  strict  nlerarcnical 
structure  leads  inevitably  to  a  succession  of 
increasingly  privileged  system^  components,  and 
ultimately  to  a  "most  privileged"  one,  which  gain 
their  privilege  exclusively  by  virtue  of  their 
position  in  tne  hierarchy.  Sucn  structures  are 
inherently  wrong  ..."  [lBj 
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Had  trie  assignment  tecnnique  been  available  to  the 
autnors  of  tne  above  statement,  tney  would  nave  been 
afforded  a  means  of  expressing  tneir  views  more  precisely 
tnan  tne  ambiguous  pnrase  "innerently  wrong".  Tne  assignment 
tecnnique  provides  a  precise  means  for  clearly  formulating 
sucn  an  observation  and  evaluating  its  validity.  As  snown  in 
section  V,  and  in  agreement  with  tfulfs'  statement,  tne 
Muitics  Ring  Mecnanism  is  "innerently  wrong"  witn  respect  to 
compromise  policies.  On  tne  other  hand,  the  Muitics  Ring 
Mecnanism  is  ".lust  rignt"  as  a  means  of  enforcing  a  program 
integrity  policy  or  assisting  in  tne  enforcement  of  the 
systems  hierarchical  as  well  as  non-hierarchical  security 
policies  (viz.,  via  Security  Kernels). 

Additionally,  in  the  same  report  [19]  the  authors  mate 
tne  following  observation  with  respect  to  tneir  overall 
design  methodology  : 


Among  tne  major  causes  of  our   inability   to 

experiment  with,   and   adapt,  existing  operating 

systems  is  their  failure   to  properly   separate 

mechanisms  from  policy."  [iej 


The  assignment  technique  has  shown,  however,  that 
lattice  security  policies  and  protection  mecnanisms  tnat 
enforce  these  policies  are  inextricablely  related. 
Recognizing  this  inseparability  should  provide  considerable 
insight  into  current  efforts  in  this  area. 
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Overall,  assignment  researcn  nas  providea  a  matnematicai 
methodology  for  unifying  tde  discussion  of  security  related 
issues.  One  may  now  properly  refer  to  an  access  mode  as  a 
realization  of  an  access  right,  a  dominance  domain  as  a 
realization  of  an  access  class  and  a  protection  mecnanism  as 
a  realization  of  a  security  policy. 
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